Open Offroaders123 opened 2 years ago
From working on some of my other projects, I realized that I think it's shouldn't specifically be the library's choice to polyfill a specific feature, by specific scenarios of course. In this case at least, I think it makes sense for the user to provide their own polyfill, if an when it's necessary. This leaves interpretation for users to more-widely use the library however they need it to be used. Say if they are using NBTify in an Electron app, they don't need to worry about a polyfill about Compression Streams, since Chromium fully supports the API. But if they are making a Tauri app, they'd have to ensure that NBTify will work in WebKit for macOS.
I think it's definitely a concern that a library needs to be aware of what the user may need to do to get the library working for them. For NBTify specifically, I think polyfills should be managed outside of the library's implementation itself, as there are a number of different ways to get compression working both in the browser and Node.
After writing all of that, I may rethink this decision actually, haha. Going to keep this issue open still, and look into the different options out there to make compression easier to work with for NBTify.
As of the recent last few weeks, the Compression Streams API is now support across all modern browsers!
This means the only issue with relying on it without polyfilling it would be in browsers before the change, and Node, which doesn't support the deflate-raw
option just yet.
As of this commit (ab4b969), NBTify is now polyfilling the usage of deflate-raw
while running in Node, dynamically importing from the node:zlib
module to fill in the support gap. This leaves the only missing support issues to arise in older browsers that don't yet support the additions (Reference: Caniuse).
In the realm of NBTify, I think this is less of an issue for the library's concerns now (thankfully! 😃). I'm going to close this issue now because of the improved browser support, which isn't only in Chromium now. That was the biggest holdup for me in regards to relying on the API without a polyfill. Not to say that it's available for everyone yet, but from hereon out, it's more of a fallback to include a polyfill, rather than something that you must* rely on for NBTify to work in most places.
For backwards compatibility (realistically now still, and eventually in the future when this will be less of a present API support issue), I recommend using either of these two libraries to polyfill the API if you want to use NBTify on a platform that doesn't quite support the Compression Streams API:
@stardazed/streams-compression compression-streams-polyfill ⭐️ (favorable, easier to set up out of the box)
*Edit: Going to leave this open as a reference to future readers.
Forgot to mention this one too. Gotta add a polyfill of the Compression Streams API for browsers that don't support it yet (I think WebKit is the only odd one out, as of now!). I've been looking at Stardazed's implementation for a bit now. I will likely use theirs or make my own edit of it, since I'd ideally only want a polyfill for the Compression part of their Streams polyfill, as that's the only missing part in modern browsers. https://github.com/stardazed/sd-streams