Future of reactphp/promise-stream

[clue]

We're currently in the process of planning the future of ReactPHP in https://github.com/orgs/reactphp/discussions/472, so I'd like to use the chance to discuss what (if any) future our reactphp/promise-stream package has.

The way I see it, the project is only used for its buffer() function for the most part (in fact, this is also why this package was born: reactphp/stream#45). If you take a look at the installation stats, you'll see that close to 100% of all installations come from reactphp/http. To make matters worse, the HTTP component has to work around some of the edge cases of buffering closed streams, so it might as well just implement 10 lines of code without an additional dependency.

I will argue that installing an entire project for a single function only is a bit overkill (for the PHP ecosystem at least). Likewise, maintaining an entire project requires a non-trivial amount of work – which I'd rather redirect towards our main components.

To add insult to injury, the package also features poorly-named first() and all() functions. This interferes with IDE autocompletion, as our Promise component also offers a prominent all() function from a different namespace. Better names might perhaps be something along the lines of bufferString() and bufferArray(). But renaming would incur a BC break, so we'd either have to wait for vNEXT or spend even more effort and add additional functions and deprecate the existing ones.

As such, I wonder if we should keep this as a separate component or we should perhaps deprecate this component and reuse the logic elsewhere as needed?

[WyriHaximus]

This is IMHO one of the packages we have that makes sense in testing and very specific edge cases. If anything and we don't need it in the core anymore I would suggest moving it to Friends of ReactPHP. Some of my package's testing relies on it. (Mainly stream modifiers.) And there are, regardless of the future of vNEXT niches where it will fit.

And I suppose this response already answers your question ;).

[clue]

Moving over to Friends of ReactPHP works for me, this would at least remove the maintenance burden for ReactPHP core. I wonder what the process would look like, i.e. when would we move this to not affect existing ReactPHP v1 but still have this done before ReactPHP v3 takes shape, also with regards to documentation of the meta repository, website, etc.

[WyriHaximus]

1. Fork repo
2. Make required changes
3. Publish new package
4. Mark old package as abandoned with link to new one and archieve repo

[fritz-gerneth]

Adding another use-case here for buffer: anything that cannot handle streams, in our case for example saving the result of a stream to Redis