@rubensworks Thank you for submitting this PR!

🔔 @eps1lon @Archcry @WilcoBakker @inlined @Alorel @KSXGitHub @parambirs @tellnes @octo-sniffle @smac89 @Flarna @mwiktorczyk @wwwy3y3 @DeividasBakanas @kjin @alvis @Hannes-Magnusson-CK @jkomyno @hoo29 @n-e @BrunoScheufler @islishude @r3nya @ajafff @mohsen1 @a-tarasyuk @eyqs @ZaneHannanAU @ThomasdenH @matthieusieben - please review this PR in the next few days. Be sure to explicitly select Approve or Request Changes in the GitHub UI so I know what's going on.

If no reviewer appears after a week, a DefinitelyTyped maintainer will review the PR instead.

@rubensworks The Travis CI build failed! Please review the logs for more information.

Once you've pushed the fixes, the build will automatically re-run. Thanks!

any only occur under object mode

any is not really helpful. If you really want to support object mode, you should create a ObjectModeBuffer and a system of functions around it.

@KSXGitHub How would you suggest defining such a ObjectModeBuffer ? read() can literally return any type, so I am not sure what this ObjectModeBuffer would look like.

@rubensworks Unfortunately, this pull request currently has a merge conflict 😥. Please update your PR branch to be up-to-date with respect to master. Have a nice day!

@rubensworks By read(), you meant readdable.read()? you can have a ObjectModeReadable#read that returns any and leave Readable#read for string | Buffer. Another alternate solution is to make Stream/Readdable/Writable generic. ObjectMode* types are returning value when one provides object-mode options (such as objectMode: true, readdableObjectMode: true, writableObjectMode: true) to functions that create Streams.

Personally, I find doing this is way too complicated that it isn't worth it. Not to mention this pull request is guaranteed to break existing TypeScript projects which have always assumed Stream contains Buffer. I also find no real use of object mode anyway.

Another alternate solution is to make Stream/Readdable/Writable generic.
...
Personally, I find doing this is way too complicated that it isn't worth it.

Agreed, this change would be pretty invasive. I'd want second/third/... opinion on this before I implement this.

I also find no real use of object mode anyway.

I'm pretty sure lots of people do have a use for object mode ;-) (This W3C community group is just one example: http://rdf.js.org/#stream-interface)

🔔 @hoo29 - Thanks for your review of this PR! Can you please look at the new code and update your review status if appropriate?

Losing type safety for the non-object mode streams does not seem optimal. In lieu of doing a substantial pull request to create an ObjectModeReadable interface, would it not be better to simply cast the stream to any in your code?

In lieu of doing a substantial pull request to create an ObjectModeReadable interface, would it not be better to simply cast the stream to any in your code?

Surely, I'm not the only one with this problem. So to let everyone experiencing this cast away the problem seems to go in against the ideas of TypeScript. So I don't consider this a good alternative.

As is stands now, the typings are simply wrong, which needs fixing. This PR does exactly that.
An ObjectModeReadable is indeed a more generic fix, but requires significant changes.

Perhaps one of the core maintainers of DT can chime in and share their thoughts?

Perhaps one of the core maintainers of DT can chime in and share their thoughts?

I'm not a core maintainer - not sure if there are ones but I can share my thoughts.

I think there is already a #26410 to address this by converting stream into generics. Quite a big PR as it requires to raise minimum typescript version to 2.4 so not sure if this will be merged soon/at all.

To my understanding this would correct the issue mentioned here plus add the possibility to use more concrete typing for e.g HTTP/TCP streams which never use object mode.

To me this looks like a good starting point.

Fair enough - I am convinced!

A definition owner has approved this PR ⭐️. A maintainer will merge this PR shortly. If it shouldn't be merged yet, please leave a comment saying so and we'll wait. Thank you for your contribution to DefinitelyTyped!

We should also watch out for breaking changes. It is guaranteed to happen.

I'm holding off on merging this until a call is made on #26410

Yeah. Presuming certain ones is awkward.

If we say that streams in normal mode return buffers, we should extend it so it has BufferModeStream, StringModeStream and ObjectModeStream<T>.
Any type is too varied.

But that'd just cause concurrency hell…

We'll be implementing typesVersions (microsoft/TypeScript/pull/26568) soon on DefinitelyTyped which should allow us to make non-backwards-compatible changes to packages like node. At that point something more type-safe like #26410 would be preferable to just using any.