deprecate stream1#pipe()

[jonathanong]

i don't think it should be supported or used anymore and i want to know when any module i use uses a streams1 implementation (so i can stop using it). everything should be streams2+.

i'm just looking for a deprecation message if it's used.

what do you guys think?

[nfroidure]

Would be a good thing imo. Stream1 based libs should upgrade or die.

[domenic]

I still use through a lot :-/

[rvagg]

go through2 then

[domenic]

through2 drags along readable-stream, which I don't want (since I only support io.js)

[rvagg]

http://r.va.gg/2014/06/why-i-dont-use-nodes-core-stream-module.html

you should still be using readable-stream because you have better ability to pin to a specific implementation regardless of io.js version being used with your libs

[domenic]

Yeah, I disagree with that post, so shrug.

[chrisdickinson]

How much code would we break, as of streams3, if we simply made Readable the new Stream base class? Or otherwise presented the old API as implemented on-top-of Readable?

Looks like this isn't feasible.

[rvagg]

I'm pretty sure Browserify wouldn't be happy

[mikeal]

I'm pretty sure Browserify wouldn't be happy

There should be a way to test that :)

[isaacs]

Making readable the new base class makes all writables duplexes, which would be weird.

I'm ok with soft deprecation, I guess.

[ghost]

browserify is more complicated because readable-stream isn't what you get when you require('stream'). It uses this project to shim out streams 1: https://github.com/substack/stream-browserify

[rvagg]

my point on browserify being that if we made it the base 'stream' return type then browserify would have to bundle readable-stream if you ever did any require('stream') which might suck a bit

[nfroidure]

+1 on Stream base class not being Readable and simply stay abstract.

[mcollina]

Closing because old and probably solved.