webpack: Can't create UMD build which can be required by Node
Do you want to request a feature or report a bug?
bug
What is the current behavior?
If you require a module in the target output UMD you get this error:
ReferenceError: window is not defined
at Object.<anonymous> (/mnt/c/Users/foo/webpack-umd-node/dist/main.js:1:272)
If the current behavior is a bug, please provide the steps to reproduce.
- https://github.com/donaldpipowitch/webpack-umd-node
$ git clone git@github.com:donaldpipowitch/webpack-umd-node.git && cd webpack-umd-node && yarn && yarn build && yarn test
What is the expected behavior?
You shouldn’t see a ReferenceError
.
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as the browser version, Node.js version, webpack version, and Operating System.
Node v8.9.4, webpack v4.0.0-beta.2
According to https://webpack.js.org/configuration/output/#module-definition-systems the UMD build should not include window
.
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 64
- Comments: 28 (5 by maintainers)
Commits related to this issue
- Improve webpack build to output single file Previously, two files were generated because umd target in webpack was not working in node. see https://github.com/webpack/webpack/issues/6522. Issue resol... — committed to dworthen/js-yaml-front-matter by dworthen 6 years ago
- workaround for https://github.com/webpack/webpack/issues/6522 — committed to wideLandscape/wrixJS by wideLandscape 6 years ago
- Fix issue with webpack 4 and node https://github.com/webpack/webpack/issues/6522 'npm run bench' now works again — committed to mfogel/polygon-clipping by mfogel 6 years ago
- Enable output modules to be used in browser or Node This makes cli.js work again from the Node command line Workaround from https://github.com/webpack/webpack/issues/6522 — committed to edemaine/KaTeX by edemaine 6 years ago
- Enable output modules to be used in browser or Node (#1401) This makes cli.js work again from the Node command line Workaround from https://github.com/webpack/webpack/issues/6522 — committed to KaTeX/KaTeX by edemaine 6 years ago
- fix(build): workaround for webpack UMD bug This is a work around for https://github.com/webpack/webpack/issues/6522. This causes certain node.js environments to be unable to `require` UMD modules gen... — committed to Zilliqa/zilliqa-js by deleted user 6 years ago
- fix(build): workaround for webpack UMD bug This is a work around for https://github.com/webpack/webpack/issues/6522. This causes certain node.js environments to be unable to `require` UMD modules gen... — committed to Zilliqa/zilliqa-js by deleted user 6 years ago
- - finally we have a standalone build that's not crashing on NodeJS. Reason? webpack4. As it says in the code: `!@#$%^Y&*(O) webpack! >:-(`. Check out: https://github.com/webpack/webpack/issues/6522 & ... — committed to GerHobbelt/babel by GerHobbelt 6 years ago
- fix: "window is not defined" error due to webpack options - https://github.com/webpack/webpack/issues/6522 — committed to jolibrain/deepdetect-js by alx 6 years ago
- Avoid problems with libraryTarget "umd". https://github.com/webpack/webpack/issues/6522 — committed to sakai-akinobu/igata by sakai-akinobu 6 years ago
- Fix webpack UMD bug This is a workaround for webpack/webpack#6522. This causes certain node.js environments to be unable to `require` UMD modules generated by webpack. — committed to zooniverse/front-end-monorepo by rogerhutchings 6 years ago
- Fix bundling in react-components (#264) * Fix webpack UMD bug This is a workaround for webpack/webpack#6522. This causes certain node.js environments to be unable to `require` UMD modules generate... — committed to zooniverse/front-end-monorepo by rogerhutchings 6 years ago
- Fix umd node target Issue at Webpack side: https://github.com/webpack/webpack/issues/6522#issuecomment-368338426 — committed to jehna/casi by jehna 6 years ago
- add globalObject definition to umd output See https://github.com/webpack/webpack/issues/6522 Partially addresses #8 — committed to alampros/retoggle by alampros 5 years ago
- add globalObject definition to umd output See https://github.com/webpack/webpack/issues/6522 Partially addresses #8 — committed to alampros/retoggle by alampros 5 years ago
- Fix UMD build Fix UMD build by setting global object that doesn't require 'window' to be present' and add node to babel targets. See: https://github.com/webpack/webpack/issues/6522 — committed to monksoftware/strophejs by LeartS 5 years ago
- Fixed module attachment in Node environment Solution provided by https://github.com/webpack/webpack/issues/6522#issuecomment-371120689 — committed to MaximDevoir/enum-bug by MaximDevoir 5 years ago
- chore(modernize): Fix SSR issue with Webpack 4 & UMD modules Why isn't this built in Webpack is beyond me Read more: https://github.com/webpack/webpack/issues/6522#issuecomment-371120689 — committed to Coriou/react-pricing-table by Coriou 5 years ago
- Fix webpack UMD for node webpack/webpack#6522 — committed to syntek-lang/syntek by SebastiaanYN 5 years ago
- Minimal SSR fix. See e.g. https://github.com/webpack/webpack/issues/6522 / https://github.com/webpack/webpack/issues/5843 and the docs at https://webpack.js.org/configuration/output/#outputglobalobje... — committed to microbit-matt-hillsdon/react-carousel by microbit-matt-hillsdon 4 years ago
Setting
globalObject: 'typeof self !== \'undefined\' ? self : this'
produces exactly the same UMD header as in WebPack 3With
target: 'node'
it throwsUncaught ReferenceError: global is not defined
if the UMD build is loaded in the browser 😄globalObject: 'this'
works for Node and the browser. Is this a new setting? I haven’t seen it before. Is this the right way to do it or is it a bug that I need to do that? I’ll update my linked example.To add to this, we ran into an issue combining optimization.splitChunks with the targetObject. To get around this, we added parens around the suggestion from @bhovhannes (https://github.com/webpack/webpack/issues/6522#issuecomment-371120689):
Our situation might be unique, but we are creating a shared library where we want to ship N components, along with a common chunk to provide at build-time with shared code between the components.
e.g.
not having parens around
(typeof window !== 'undefined' ? window : this)
resulted in the following code in the commons chunk:Clearly in the browser that first conditional will be false
typeof window === 'object'
, causing the rest of the ternary op to be ignored andwindow.push
to be run.Adding parens around the globalObject outputs this code:
It’s a hack that really depends heavily on the internals of webpack, but I don’t see another way around it until this is solved.
Sorry if this doesn’t work for you, this is DEFINTELY a “works on my machine” kinda solution
@zacharyfmarion @yairEO I found a solution; add the following line to your webpack.config.js.
globalObject: "typeof self !== 'undefined' ? self : this"
. Kind of frustrating that webpack hasn’t fixed the bug yet though.@aendrew We are based on browserslist by default, if you support
globalThis
by versions, we will useglobalThis
and it will work everywhereAccording to the docs include
output.globalObject
into webpack.config.js:To make UMD build available on both browsers and Node.js, set output.globalObject option to ‘this’.
// Rant mode on That hilarious, as i see it was in 4 beta already. Now its 4.8.3, and its still there without a proper fix. Spent a day for this. Behaviour so inconsistent that i wanted to break something xD So many combinations and only one really worked for me. // Rant mode off
Proposed solution from above ( globalObject: ‘typeof self !== 'undefined' ? self : this’ ) simply dont work for me in browser. my lib
my import logging code
On server it as expected produce
import { default: { x: 'y' } }
In browser it produceimport {__esModule: true}
So empty module in browser for some reason. If i setglobalObject: 'this',
It almost worked. On server it was fine like in previous case. But in browser it wasBasically it was adding for some reason mylib in browser. But not in node. Really consistent… And only removing from config
library: "mylib",
made it behave same for me in browser and node.TLDR ONLY
globalObject: 'this'
AND removing option from configlibrary: "mylib"
made it work same in browser and node for me. And im not really sure yet if it will work properly or no. It just feels so hacky and inconsistent that it might break anytime. And the fact that it behave differently from the solution\comments from above just make that feeling worse…any updates? migrate from webpack 4 to 5 ejected CRA app - and if do “globalObject: ‘this’” then my build is broken
hmm… I see.
Try
target: "node"
oroutput.globalObject: "xxx"
@vbabak This is not working anymore somehow once I add:
to my webpack config 🙁
Since the issue has been open for nearly a year, it does not appear a fix will be forthcoming. In that case, perhaps the solution is to add the work-arounds mentioned here to the documentation pages:
Thanks, at first I thought this in combination with setting
libraryExport: 'default'
allowed me to require my modules as expected with CommonJS.However, I see quite strange, seemingly random behavior with the following actions:
webpack --mode development
webpack --mode development
again:webpack --mode development
againwindow
againSimilarly random behavior can be seen by running
webpack --mode development --watch
, then saving a file with or without making any changes. One of the following 2 results occur:window
The strange thing is that when saving a file without any changes being made, bundle.js is not even rebuilt; but still, the line
})(typeof self !== 'undefined' ? self : this, function() {
randomly changes back and forth to})(window, function() {
.One thing I tried was deleting
node_modules/.cache/babel-loader
(as I was setting cacheDirectory to true in development mode). But turning that setting off and deleting.cache/
entirely made no change to the above behavior.Edit: Also tried deleting node_modules and running
npm install
for a clean slate just in case there was some kind of webpack cache buried inside, although I’m not sure that’s actually implemented (unplug it and plug it back in). No change to above behavior.Should I create a separate issue for this, or does it seem related? Let me know if more environment details are needed.