Encountered compilation errors related to SharedArrayBuffer about is HOT 7 CLOSED

I found a different workaround for this. TypeScript 3.1.1 fixes microsoft/TypeScript#26497, which means it now preserves directives. So the workaround is to duplicate the tslint config lib property as directives. Annoying to have to duplicate this, but at least it fixes the problem for now.

from is.

We have lib.es2017.sharedmemory in our config, but I didn't think that would be required for consumers too. It's weird that TS handles it like this, unless I'm missing something.

@SamVerschueren Any ideas?

from is.

You can set skipLibCheck to false. See https://www.typescriptlang.org/docs/handbook/compiler-options.html. By default, TS checks all shipped type definitions in node_modules as well. But I agree that it's weird for consumers to care about this. Will dive deeper into it when I have some more time.

from is.

On the other hand, if you want to use the type definitions, you as a consumer also needs to know what SharedArrayBuffer is. So the error might make sense.

from is.

This boils down to the fact that the TypeScript compiler does not attempt to remove references to SharedArrayBuffer even when the compiler target set to es2016. For example const foo = new SharedArrayBuffer(4); compiles to const foo = new SharedArrayBuffer(4);. So strictly speaking, when your lib includes lib.es2017.sharedmemory and your target is set to es2016, the actual target JavaScript environment should be thought of as "es2016 + a SharedArrayBuffer polyfill". By the same token on the TypeScript side, the consumer's lib must include lib.es2017.sharedmemory.

Now specifically in the case of this project it just so happens that the .js output does NOT include any references to SharedArrayBuffer. So while in theory this project's compiler setup would require SharedArrayBuffer to be present in the target execution environment, in actuality it does not. No such luck on the TypeScript side. The .d.ts files most definitely have references to the global type SharedArrayBuffer and the consumer must include lib.es2017.sharedmemory if they want to use this.

I can think of a couple ways to close this issue:

1. (My preference): Remove SharedArrayBuffer as one of the things that this library knows how to type check. Of course this change would not be backwards compatible. Perhaps that feature could be split off into its own package.

2. Add a short note of documentation to the README explaining that if you're using TypeScript this package requires lib.es2017.sharedmemory.

If folks 👍 one or the other of these approaches I'd be happy to take a stab at the "fix".

from is.

(My preference): Remove SharedArrayBuffer as one of the things that this library knows how to type check. Of course this change would not be backwards compatible. Perhaps that feature could be split off into its own package.

I'm ok with this. I don't think many would use this check yet anyway. We can reintroduce it some time in the future.

@carnesen Would you be able to open an issue on the TypeScript issue tracker about this? There really should be a way for a library to include lib.es2017.sharedmemory without the consumer having to care about it. Maybe some kind of directive comment.

from is.

TypeScript issue: microsoft/TypeScript#27416

from is.