Use of SharedArrayBuffer in index.d.ts

[rfreedman]

I'm using exifr in an Angular 8 / Typescript application.
"production" compilation fails due to presence of SharedArrayBuffer in node_modules/exifr/index.d.ts

The line is

type Input = ArrayBuffer | SharedArrayBuffer | Buffer | Uint8Array | DataView | string | Blob | File | HTMLImageElement

I'm not sure if, for general consumption, SharedArrayBuffer needs to be an input type, but I'm not using it as an input type, and it breaks my build.

I solved the issue by overriding index.d.ts with a copy with SharedArrayBuffer removed, in my application's directory, by pointing to it in tsconfig.json.

If you think that removal of SharedArrayBuffer is appropriate for the distribution version, and don't want to make the change yourself, let me know, and I'll submit a pull request.

Thanks!

rfreedman@chariotsolutions.com

[MikeKovarik]

Hello, thanks for checking in.

I briefly looked into it and I don't understand how this can happen. SAB was invented for browsers
years ago andd has been supported by Nodejs as well for some time now. So I am confused why that breaks for you. Could you tell me more about your build process, config, the errors it throws, build targets. Are you perhaps targeting older browsers that don't support SAB?

I'd rather first try to solve the issue differently rather than straight out deleting SAB from supported types because I can see someone messaging me "you said exifr works in workers but typescript says otherwise"

[rfreedman]

Thanks,

Yes, it turned out that I was targeting an older version of JS - I updated my tsconfig to have "target" set to es2015 and "lib" set to es2018 (which are apparently the new default settings for Angular apps), and it all compiled and ran fine without overriding the declaration file.

Thanks again!

[MikeKovarik]

Awesome. Than I'm closing this as a non-issue.