Specifying lib: DOM and WebWorker should not be mutually exclusive

[armandn]

I got myself into a situation similar to #11093.

My project is designed to work either in the "main thread", with access to DOM, or as a WebWorker, where a different behavior kicks in. This was done for compatibility reasons and to have only one distributable js file and it's been working fine for the last two years.

In all this time I never specified the lib compiler option, only target ES5.

Today, as I'm experimenting some ES2015 stuff, I see that if I specify targets DOM,ES5,WebWorker,ES2015.Promise all hell breaks loose with errors. - Duplicate identifier, Subsequent variable declarations must have the same type.

Shouldn't this kind of mix be allowed in a project?

[DanielRosenwasser]

Unfortunately the base APIs for WebWorker and DOM are actually meaningfully different, and it's not clear at this point how to write a clean separation of global scopes between different parts of your project other than splitting your project into multiple parts.

[kitsonk]

We have found that what is meaningful in the global scope of a web worker is significantly more narrow than we find out of the DOM. So we tend to author with "lib": [ "dom" ] and then just declare the handful of APIs we require to make a web worker work, or we obtain a reference to the global object, treat it as any, and pick off certain properties from the global scope and type them at the point where we pick them off.

While it isn't ideal, it saves us from the only other realistic option, splitting the code. If you have modular code, and pick off parts of a global scope and type them, and you are using modular code, you should be able to author isomorphic modules fairly easily. Here is an example of the most "bullet proof" way to get a reference to the global scope, which avoids any issues with CSP:

const globalObject: any = (function (): any {
	if (typeof global !== 'undefined') {
		// global spec defines a reference to the global object called 'global'
		// https://github.com/tc39/proposal-global
		// `global` is also defined in NodeJS
		return global;
	}
	else if (typeof window !== 'undefined') {
		// window is defined in browsers
		return window;
	}
	else if (typeof self !== 'undefined') {
		// self is defined in WebWorkers
		return self;
	}
})();

[shamhub]

@kitsonk But, do I need to write your above code in every file? and use globalObject for referring properties
How do I handle this scenario in here?

[charlesbodman]

@shamhub , no, you would use the global object instead of self

import globalObject from 'globalObject'

globalObject.postMessage({});

That being said, in your case, you don't need the global object. If you want to get around the typing errors, you can just use

const ctx: Worker = self as any;
ctx.postMessage();

[shamhub]

@charlesbodman I have used second option but I get error No webworker support as mentioned here

[charlesbodman]

@shamhub , it's because you're checking for worker support inside of the worker. No need.

[shamhub]

@charlesbodman Yes it works now. In JS, we have SharedWorker object. Am trying to execute the same code using let worker: SharedWorker = new SharedWorker('worker.js'); but I see the error Cannot find name 'SharedWorker'

[mhegazy]

SharedWorker needs to have its own lib file. mind filing a new ticket to track creating that.

[mhegazy]

logged #24323 to track adding SharedWorker support