-
Notifications
You must be signed in to change notification settings - Fork 30.1k
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
zlib: split JS code as prep for non-zlib-backed streams #24939
Conversation
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences.
this._chunkSize = chunkSize; | ||
this._defaultFlushFlag = flush; | ||
this._finishFlushFlag = finishFlush; | ||
this._nextFlush = -1; | ||
this._info = opts && opts.info; | ||
this._defaultFullFlushFlag = fullFlush; |
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.
This is fine, it mirrors the other flush flag fields (triple alliteration bonus!), I just wonder when it would be anything but Z_FULL_FLUSH
? Is it different for brotli?
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.
Yes, brotli uses a different set of constants that don’t map 1:1 to zlib’s ones (BROTLI_OPERATION_FLUSH
would be the one in this case)
const handle = new binding.Zlib(mode); | ||
// Ideally, we could let ZlibBase() set up _writeState. I haven't been able | ||
// to come up with a good solution that doesn't break our internal API, | ||
// and with it all supported npm versions at the time of writing. |
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.
Is this because of npm doing something dumb or naughty?
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.
npm uses https://www.npmjs.com/package/minizlib, which until very recently provided an API similar to our own zlib
API using process.binding('zlib')
, so they effectively locked us into an API contract for the native binding. I’ve had a PR to (at least to some degree) address this merged & released last week, so it’s probably just a matter of slowly waiting for already-released npm versions to become outdated now…
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.
First released in 2017?! You'd think Isaac learned from the graceful-fs debacle two years before but I guess I'm a hopeless optimist.
Well okay, let's give npm one more pass. Don't want to punish the community for the actions of an individual.
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 have a very difficult time being sympathetic to minizlib here. Our policy around process.binding has been very clear. If we break that module making necessary changes to the binding then so be it
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.
@jasnell Yes, it’s unfortunate that we can’t do a bit more cleanup here yet, but I don’t think there are any necessary changes to be made here. Plus, whether we like it or not, I don’t think breaking every version of npm that is in use is something we could realistically do.
Another review would be great here. @indutny @mscdex @joyeecheung @jasnell |
Landed in 3b9e0f2 |
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. PR-URL: #24939 Reviewed-By: Ben Noordhuis <[email protected]>
This does not land cleanly on v11.x, should it be backported? |
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. PR-URL: nodejs#24939 Reviewed-By: Ben Noordhuis <[email protected]>
Backport in #25228 |
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. Backport-PR-URL: #25228 PR-URL: #24939 Reviewed-By: Ben Noordhuis <[email protected]>
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. PR-URL: nodejs#24939 Reviewed-By: Ben Noordhuis <[email protected]>
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. Backport-PR-URL: #25228 PR-URL: #24939 Reviewed-By: Ben Noordhuis <[email protected]>
Split the `Zlib` class into `ZlibBase` and `Zlib` classes, to facilitate introduction of similar streams with minor implementation differences. Backport-PR-URL: #25228 PR-URL: #24939 Reviewed-By: Ben Noordhuis <[email protected]>
Split out from #24938
Split the
Zlib
class intoZlibBase
andZlib
classes,to facilitate introduction of similar streams with minor
implementation differences.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes