-
Notifications
You must be signed in to change notification settings - Fork 29.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
stream: use an assertion for weird error cases #27073
Conversation
These two cases should only happen in case there's a bug in our implementation or the user manipulated things pretty bad. So instead of using our regular error system for these two cases, use a simple assertion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t think we should land this, I would need to add assert to readable-stream dependencies
I'll keep being -1. I prefer not having to load anything from |
@mcollina in what way would you have to polyfill that part? It only loads an internal error and AFAIC those are now also ported to Do you suggest to keep it as is instead? We could also remove the code completely instead of keeping a sanity check shrug. |
Essentially I would have to write some regular expressions to replace the usage of that module with something that does not need a require.
Yes, I would prefer to keep this as-is. |
I suggest that this is looked at again at some point since this is pretty much dead code and not coverable when not done as assertion as I did. |
These two cases should only happen in case there's a bug in our
implementation or the user manipulated things pretty bad. So instead
of using our regular error system for these two cases, use a simple
assertion.
I guess this should be semver-major even though it has always been just a sanity check (from the original implementation on).
@nodejs/streams PTAL
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes