Support multiple TypeScript entry points

[tobalsgithub]

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 ES2016 to compile and I hit this error

node_modules/avsc/types/index.d.ts(148,41): error TS2304: Cannot find name 'Blob'.

Typescript: 2.9.2
Node: 8.11.3

It appears that Blob is 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 --skipLibCheck which gets me around the problem.

[mtth]

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 --skipLibCheck is 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?

[andrew8er]

You may need to add "dom" to your lib section in your tsconfig.json:

{
  "compilerOptions": {
    "lib": [
      "dom" // ...
     ]
  }
}

[TysonAndre]

It's been a while.

I may have been using avsc from 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.

[tobalsgithub]

@andrew8er, adding dom to my lib does in fact help, but that doesn't feel like the right thing to do. The challenge here is that Blob and other stuff from the dom really 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 createBlobEncoder and createBlobDecoder depending 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.

[andrew8er]

I am not using this project currently, so I do not really know how Blob is used here, but you are totally right. That dependency should be made optional and explicit.

[reuzel]

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?

[mtth]

Would 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.