Use 'stream' instead of '_stream_transform'

[billiegoose]

Fixes #1

[jessetane]

Hey thanks for the patch. First, this library is not really maintained, any reason you reached for this instead of through2? Second, I think the reason I wrote this originally was because I was using it in the browser and wanted to cut down on bundle size - so it probably still makes sense to pull in the dep directly which is slightly more compact than grabbing the entire package. See how through2 does it for example:
https://github.com/rvagg/through2/blob/master/through2.js#L1

[billiegoose]

I thought that might be what you were going for, but I don't think it is because https://github.com/nodejs/readable-stream/blob/master/transform.js#L1 just kind of undoes any advantage. And before you think changing it to get readable-stream/lib/_stream_transform might give you that advantage, take a look - the first think _stream_transform does is pull in Duplex, and then Duplex pulls in Readable and Writeable.

That being said, I suppose the thing to do would be to actually try both approaches and look at the resulting bundle size. Maybe I'm missing something.

any reason you reached for this instead of through2

50% less characters! :) Actually...

At some point a couple years ago I realized that a) All I ever use are object streams, b) through2.obj keeps making me have an "enc" argument that I never use. So I wrote my own module with the reduced feature set I actually used, and thought "wouldn't it be need if I published it as thru because it's like "through2.obj" but more concise?" and then when I went to publish it on npm, I discovered low and behold the module already existed and had exactly the same API! So I took it as a sign and have been using thru ever since, lol.

[jessetane]

Yeah it just doesn’t pull in pass-through. Not a huge thing but why not save a few bytes?

[billiegoose]

For the record, I have done an actual comparison (using hughsk/disc) to see what the difference is:

You are indeed correct. The change I proposed would bump the bundled size from 140.8kb to 143.2kb. That's 2.4kb more for very little benefit. As much as it pains me to see weird private Node core APIs with underscores... I think the correct approach to close #1 is to get "_stream_transform" added to builtin-modules. And if that's not possible, to get it added to jest-resolve.

[jessetane]

How does require('readable-stream/transform') compare? I would accept a patch for that if it makes sense.

[jessetane]

That could have its own pitfalls though, a direct dep on readable-stream might clash with the version pulled in automatically by browserify if other packages require stream. So maybe your initial version makes the most sense after all? Also, with a bundle size of 140k, the size increase is less than 1% overall, which seems a small price to pay to just use the standard interface and avoid this complexity... honestly I have not found myself using node streams in the browser recently so I really shouldn't be advising here :)