make SharedStdIn visible to non-test code#2396
Conversation
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
There was a problem hiding this comment.
Code Review
This pull request promotes the SharedStdIn class to a public API by removing the @VisibleForTesting annotation. Feedback indicates that the implementation needs to be more robust by propagating onDone and onError events to avoid hanging subscribers. Furthermore, the class documentation is now outdated and should be updated to reflect its public status and include warnings about potential StateError usage.
PR HealthLicense Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
This check can be disabled by tagging the PR with Breaking changes ✔️
This check can be disabled by tagging the PR with Coverage ✔️
This check for test coverage is informational (issues shown here will not fail the PR). This check can be disabled by tagging the PR with API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
This check can be disabled by tagging the PR with Unused Dependencies ✔️
For details on how to fix these, see dependency_validator. This check can be disabled by tagging the PR with Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. This check can be disabled by tagging the PR with |
| final SharedStdIn sharedStdIn = SharedStdIn(stdin); | ||
|
|
||
| /// A singleton wrapper around `stdin` that allows new subscribers. | ||
| /// A wrapper around a stream that allows new subscribers, intended for use |
There was a problem hiding this comment.
If the class is public and intended to be used (only!) on other streams than stdin, then the name is confusing.
Could just name it [SharedStream]. And move it to package:async.
Why restrict it to Stream<List<int>>?
Because it also has line-based operations, I assume.
Actually, that's a very, very flaky design. It multiplexes events between listeners.
If one listener reads a line, then cancels, if that event contained bytes beyond the first line,
those bytes are lost. They're not buffered and passed to the next listener.
Or if they read lines, and get an event that doesn't contain a line ending, and then they
cancel before the next event, the entire event is lost.
It might work for stdin, if we know that input events are always separated at line breaks,
and nobody cancels between receiving events. Very fragile API.
For any other input, it's really not a class I can recommend.
Which means it's not a class we should make public, or use for any class other than stdin.
(If even that. Could use some serious clean-up.)
If we want this to be shared, it should be improved so it is actually built for controlled-length reading of text or bytes, and does not rely on the input being split into events in any particular way. Could use StreamQueue, maybe the line reading is actually a match for the transaction API.
(And we should add good testing that this class actually works for stdin.)
There was a problem hiding this comment.
The use case here really is for stdin, just using a version of it that actually works fully on windows for things like arrow keys.
While valid, I don't believe your concerns are relevant to this PR? All this does is expose the constructor, an instance of the class was already available, but regular stdin from dart:io is very limited on windows.
Closes #2395