Repository navigation
Support multiple TypeScript entry points #219
Description
Activity
Hey @tobalsgithub, I don't know enough about TypeScript typings to say what the best way forward is; from reading the issue you linked, it sounds like
--skipLibCheckis a reasonable approach. Perhaps @andrew8er, @TysonAndre, or @reuzel (typing authors) have any ideas? I'm also curious why this issue has not popped up before, did something change recently?You may need to add
"dom"to yourlibsection in your tsconfig.json:{ "compilerOptions": { "lib": [ "dom" // ... ] } }
Reacted by Taras NovakIt's been a while.
I may have been using
avscfrom a project that added its own polyfill of Blob (e.g. sinon).Or maybe I wasn't generating/validating the stubs in strict mode and didn't see that warning.
@andrew8er, adding
domto mylibdoes in fact help, but that doesn't feel like the right thing to do. The challenge here is thatBloband other stuff from thedomreally should not compile in node. They're not available in node, and thus allowing typescript to compile with them leads to unexpected runtime behavior.It feels like the right solution here would be to somehow conditionally include the type definitions for
createBlobEncoderandcreateBlobDecoderdepending on the environment.Here's a discussion that looks related. May just be something we have to workaround for the time being. microsoft/TypeScript#449
I appreciate y'all taking a look.
Reacted by Taras Novak, Antonio Juliano and Corinne HoenerI am not using this project currently, so I do not really know how
Blobis used here, but you are totally right. That dependency should be made optional and explicit.In my project I am using the blob functionality. I have an API that is used to stream a large set of data points from server to client. To save on bandwidth and serialization effort I use this library to create a condense, compressed format of that data. The blob feature is used on the client side to get access to the underlying data stream. As such I would like to have this functionality in.
Would it not be possible as a workaround to use two entry points into the package? One for node, the other for web?
Reacted by Andrew KaiserWould it not be possible as a workaround to use two entry points into the package? One for node, the other for web?
That sounds like a good idea (we actually already do it for JavaScript), I'd be happy to merge a PR which implements a TypeScript equivalent.
- changed the title
[-]Types don't compile in node - Cannot find name 'Blob'.[/-][+]Support multiple TypeScript entry points[/+]on Mar 31, 2019
Ran into an issue compiling the type definitions in typescript in a node environment. I'm using this command
tsc --outDir bld --module commonjs --target ES2016to compile and I hit this errorTypescript: 2.9.2
Node: 8.11.3
It appears that
Blobis a global exposed on browsers but not available in a node environment.This issue discusses the same problem for a different library. DefinitelyTyped/DefinitelyTyped#12044
I'd make a PR to fix this, but I don't actually know what the right solution is here. It feels like an anti-pattern to have the type definitions depend on something globally available only in certain environments, but I'm not well versed enough in typescript to know how to handle such a situation.
For now, I've changed my compilation command to
tsc --outDir bld --module commonjs --target ES2016 --skipLibCheckwhich gets me around the problem.