nodeca
Extra maintainers
Hey! Would you be open to accept new maintainers to help steward the library?
We would love to use pako at Lokalise, but are somewhat concerned about lack of recent updates. We'd be happy to lend a hand with that, if you would have us.
Could you explain what kind of maintenance do you need/expect? IMHO, the codebase is stable for many years (one known problem with multistream unpack, and nothing else)
@puzrin Basic stewardship. Ensuring CI is executed on newer Node versions, triaging issues when reported, refining documentation, keeping up with recent linters etc. No big revolutions, just steady janitorship.
To be honest, I prefer a conservative approach: "no changes just for fun." But if you think some changes are important for you, I'd propose posting an issue with a general plan to discuss, and I can promise to land PRs with coordinated changes as soon as possible.
no changes just for fun
I understand it's totally fine for pako doing this. While I believe there are a bunch of users that want's a zlib pure JS implantation.
If this is the actual goal, then we are expected to target LTS node versions and last 1/2/3 years major browsers, and we would like to use modern syntax to maximum its performace, and keep devDeps (linter, bunders, .etc) be rolling with ES/Node version, also we are expecting CI checks on very Node.js version (18,20,22,24)
I believe at lest the above is also reasonable.
I am not sure if it is @kibertoad's expectation, but I think at least we are similar.
Also I think it's important to move this repo towards ESM, ESM can improve tree shaking.
I am not happy that Deflate gzip deflate are bundled as well when i just want deflateRaw
Now there is - https://developer.mozilla.org/docs/Web/API/Compression_Streams_API
+ https://web.dev/blog/compressionstreams
So perhaps the question of maintainers need not be asked.
I prefer a conservative approach: "no changes just for fun."
@puzrin THANK YOU!
Now there is - https://developer.mozilla.org/docs/Web/API/Compression_Streams_API
- https://web.dev/blog/compressionstreams
So perhaps the question of maintainers need not be asked.
The compression streams API is relatively slow compared to Pako for smaller payloads (under say 10kb). There must be some kind of heavy initialization going on with that browser API that makes it slower.
