Become resilient to lack of global variable

[Andarist]

Huge amount of users are compiling the lib from the source code when using bundlers like webpack, rollup and probably others.

Having a global variable is not guaranteed! I.e. with webpack3 we can specify node: false option to stop any node specific polyfills being added to the bundle - this makes global undefined and thus this lib stops working.

Imho we shouldnt rely on having it because it requires bundlers / users to provide it.

I'm committed to making a PR fixing this, but first I would like to establish if its something you would like to follow and how this should be accomplished - i.e. by wrapping detecting what global is in a module and importing it whenever we need it, or maybe some simple checks against undefined would suffice - but that needs more investigation later.

[brycekahle]

global is aliased to window in browserify. It should be trivial to do something similar with other bundlers.

[Andarist]

Sure it aint really hard, but now we have a situation when shipped code is not usable on its own, which I consider a bad thing.

[brycekahle]

The code as written works without modification in Node.js. It is 100% required to use some sort of bundler to use in the browser (if you don't want to use the pre-built versions available in repo and on several CDNs).

What use case are you working on? This library needs references to window in a browser. It would theoretically be possible to do without in Node.js, but would result in duplication of some of the currently shared code.

[Andarist]

Well, I've just assumed that the library targets to be isomorphic and is doing so by assuming global is provided by a bundler. I don't really have any use case here, just had to provide global manually in my bundle, because of this and thought that it could be avoided in the future for others, so I've filed the issue while also offering to help with the change if we agree if and how it should be done.

[lucidlemon]

Any update on this? It's really a pain in the ass to handle these errors.

[Andarist]

Imho the best option would be to just create a global module which would export appropriate global variable based on a simple check and import this in every module which needs a reference to it instead of reaching to a global namespace.

Bryce seemed unconvienced when ive raised this issue though. Maybe could be reconsidered? Or closed as not wanted.

[filipesilva]

Heya, I'm also looking into this case in the context of Angular CLI (angular/angular-cli#5804).

We use webpack-dev-server as a development server, which in turn uses sockjs-client. Due to sockjs-client needing global to be present, webpack has to include at least the node.global (https://webpack.js.org/configuration/node/#node).

That's ok insofar as getting the dev server to run. But for browser apps it is incorrect to have global present. If a browser app looks for global, it should not be there because it is not a node environment.

There is a concrete case where this is problematic right now: mapbox/mapbox-gl-js#4359 (which is at the root of angular/angular-cli#5804). The comment there explains the problem pretty well, but the TLDR is that uglifying code that relies on webpack wrapping breaks with webworkify.

It is true that there are a bunch of ways the symptom can be fixed in packages that use sockjs-client (and even using the prebuilt js files). But it looks to me like the lines below are trying to figure out a fallback to when crypto isn't available:

sockjs-client/lib/utils/browser-crypto.js

Lines 3 to 17 in 0d8627f

	if (global.crypto && global.crypto.getRandomValues) {
	module.exports.randomBytes = function(length) {
	var bytes = new Uint8Array(length);
	global.crypto.getRandomValues(bytes);
	return bytes;
	};
	} else {
	module.exports.randomBytes = function(length) {
	var bytes = new Array(length);
	for (var i = 0; i < length; i++) {
	bytes[i] = Math.floor(Math.random() * 256);
	}
	return bytes;
	};
	}

Since sockjs-client seems to be the browser client, I think it's reasonable for it to have a browser safe source code. This is of course not truly feasible since the source uses require() as well. But that doesn't mean that it shouldn't be safe in it's usage of global.

[FrozenDroid]

This is also a problem with Angular 6. Are we getting this fixed?

[aceleghin]

I have the same problem with angular 6, any fix/ workaround?

[drenda]

Same problema with Angular6. Any advice? Thanks

[mistermaek]

I have this problem as well and needs this very urgent. Any ideas? Thanks in advance.
Does somebody has any experience in getting websockets running with angular6 and spring boot websocket on server side? Any tips will be very appreciated.
Thx.

[michaelmarshall]

I have websockets working with Angular 6 and Spring Boot over sockjs and stomp.

One way to clear up this sockjs issue is to remove sockjs from your Angular app and use a cdn instead. Uninstall sockjs then add this to your index:
<script src="https://cdnjs.cloudflare.com/ajax/libs/sockjs-client/1.1.4/sockjs.min.js"></script>

Then add this after the imports in an angular component you want to use sockjs in:
declare var SockJS;

This should let you follow the tutorials out their without any issues. Here are two tutorials I used to get Spring and Angular websockets working (using sockjs and stomp):

Angular + Spring
Spring