Webpack-dev-server: Weird error about global.WebSocket

[quangbuule]

var global = (function() { return this; })();

/**
 * WebSocket constructor.
 */

var WebSocket = global.WebSocket || global.MozWebSocket;

global is undefined so, it throw error. But when I test using ws with browserify, it was window.

I am trying to use react-hot-loader and can't figure this out.

My config for entry is:

[ 
  `webpack-dev-server/client?${webpackDevServerUrl}`,
  'webpack/hot/only-dev-server',
  'src/js/index'
]

Hope someone who experienced this could help. Thanks a lot.

[EvHaus]

I'm having the same issue, but it's only occurring when running the app on Windows. The app loads fine on Mac and Linux.

The error comes from this file: node_modules/webpack-dev-server/node_modules/socker.io-client/node_modules/engine.io-client/node_modules/ws/lib/browser.js

It seems that file can't reference this. Furthermore, patching that file, results in other files having issues referencing the window object too.

[quangbuule]

Yeah right, in webpack (function() { return this; })() doesn't return window like in browserify, even when I set target: 'web' in configuration.

[sokra]

Strict mode changes (function() { return this; })() to undefined. So the module is propably not expected to run in strict mode, but some loader add the use strict. (babel?)

[gaearon]

Yeah. The solution is _not_ to process node_modules with any loaders (including Babel). This will also speed up the compilation.

You can either put exclude: /node_modules/ or something like include: path.join(__dirname, "src") in your loaders.

[EvHaus]

For me, it looks like my exclude regex doesn't work on Windows like it does on Linux/Mac. My exclude for babel is /node_modules\/(!?ux|custom)/ because I have two node_modules (one called ux and one called custom) that I want to be processed by babel.

However, you have correctly pointed to the issue. It seems that the regex isn't working as expected because all node_modules are being processed. I've changed my exclude rule to the following include rule instead:

include: [
    path.resolve(__dirname, "html"),
    path.resolve(__dirname, "node_modules/custom"),
    path.resolve(__dirname, "node_modules/ux")
],

And this resolved the issue for me.

However, I still think there's a webpack bug here because the original exclude rule should have worked. It works for Mac/Linux but does not work on Windows.

[jhnns]

Babel is driving me nuts! You can't just put "use strict" before every code...

[gaearon]

However, I still think there's a webpack bug here because the original exclude rule should have worked. It works for Mac/Linux but does not work on Windows.

Windows uses \ as path separator. You have an explicit \/ in your exclude rule. Better use include!

[Couto]

Oh boy.... I truly don't envy developers that use Windows.

[sokra]

Me is also using windows... :smile:

[jedmao]

Related webpack issue https://github.com/webpack/webpack/issues/278

[jedmao]

@Couto the issue is not developers using Windows. The issue is developers who do anything having to do with file paths w/o any regard to other operating systems. It goes both ways. I'm a Windows developer and I always use the path API when dealing with paths. If everyone else would do the same, the world would be a better place.

[jedwards1211]

@gaearon thanks a bunch for that tip! I didn't even realize Babel was processing my node modules, now it builds about 30X faster!

[synthomat]

I don't fully understand, how ignoring node_modules helps to solve this issue. My frontend-application is using dependencies from node_modules which need to be processed/compiled by babel (visjs for example). Maybe I just misunderstood webpack (╯°□°）╯︵ ┻━┻

EDIT: @globexdesigns oh, thx. That kind of helped

[gaearon]

@synthomat

It solves the issue because most dependencies _don't_ assume you'll try to compile them with Babel.

If your dependencies want to be compiled, you should file an issue with those dependencies, or include them explicitly.

However you should understand, for example, that those dependencies may want a different version of Babel or different settings.

[synthomat]

@gaearon yeah, understood. Include works great. Thanks!

[DanilloCorvalan]

And what if you need to babel some modules in node_modules ? Is there any way to avoid this problem ? :(

[SpaceK33z]

@DanilloCorvalan, see webpack/webpack#2031 for that issue.

[andy0130tw]

I think the more correct way to get window is Function('return this')() instead. The content in Function constructor is non-strict regardless of the environment it is created in.