Streams are not generic

[surma]

TypeScript Version: 3.0.0-dev.20180626

Search Terms: TransformStream Streams ReadableStream WritableStream

WHATWG streams can be used for more than just ArrayBufferViews. For example, they can be used to build observables that carry events.

lib.dom.d.ts is not only missing TransformStream, but is also not implemented with generics. @types/whatwg-streams provides a correct implementation, but it can’t be used as it conflicts with lib.dom.d.ts, and I have found no way to fix that on my end,

lib.dom.d.ts should definitely be updated, but we should also talk about the fact that there doesn’t seem to be a way to overwrite whatever the standard lib provides.

[mhegazy]

PRs welcomed. You can find more information about contributing lib.d.ts fixes at https://github.com/Microsoft/TypeScript/blob/master/CONTRIBUTING.md#contributing-libdts-fixes.

[surma]

Cool! Will open a PR for the streams.

Are there any plans/ideas to allow developers to override types specified by the stdlib?

[mhegazy]

Declarations in the lib file are not any special. So not sure what you mean by "override". but you can always use --noLib and have your own lib file.

[surma]

So in my scenario above I found the types for ReadableStream and WritableStream from lib insufficient. I found ones that suited my needs in DefinitelyTyped, but couldn’t use them as tsc complains about conflicting definitions.

You are right that I could use --noLib, copy lib.dom.d.ts and monkeypatch my types — but doesn’t that seem like a really big hammer for a rather small problem?

I am obviously not familiar with the TypeScript internals, so my idea should be highly scrutinized. I was envisioning something along the lines of:

/// <reference undeclare="ReadableStream" />
/// <reference types="@types/whatwg-streams" /> 

[surma]

(Also, I realize I am completely hijacking this issue. Should I open a new one?)

[mhegazy]

You are right that I could use --noLib, copy lib.dom.d.ts and monkeypatch my types — but doesn’t that seem like a really big hammer for a rather small problem?

As i noted earlier declarations in library files are not different from any other declarations. so the issue really is about granularity. we think of the dom today as a single group of declarations, you either take them all or not. it is possible that int he future we split the lib.dom.d.ts into multiple files, one for each dom proposal/area. in that sense you can opt-in the parts of the dom you need.

having said that, from experience, these declarations are better be updated in the default library. most ppl do not want to go mix and match their declarations and manage them independently. So in short i think the best route here is to update lib.dom.d.ts rather than going to DT for such changes.