Closed ZeeCoder closed 4 years ago
Glad you have an issue for this. I would go one step further and suggest this should be the default build, not just a special /no-polyfill
entrypoint. Polyfills should never be baked into a utility library IMO, it's an antipattern. It's wasteful for app developers who are targeting specific platforms like Electron, or those who are using something like polyfill.io. You can always add some instructions to the readme for people who need help doing it.
Same could be said for Babel, actually. I'm currently transpiling the code for the following browsers.
Some of this you might not even want to support, or you might need to support older ones. 🤷♂️ I think it is a fair assumption for this lib's users that they should have a build step and to transpile / polyfill their code to whichever browsers they need to support. 🤔
Later versions of CRA for example automatically transpiles node_modules as well. (Thanks to Babel 7 that made it possible.)
This would also make the builds lighter: ESM: 2.3K => 1.1K (460B minified) CJS: 2.5K => 1.2K (578B minified)
Not to mention the amount of KB I could save by removing the polyfill, as currently this lib shows up as 8.7K minified (!) with the polyfill. 😅
I'll sleep on it.
Could be v5.
On second thoughts one might not have the right setup to compile node modules.
I might have a raw src version (default) and a compiled one. (To es5 essentially.) Then leave instructions on polyfilling, as that's definitely doable regardless of bundler.
In some cases you might not need a polyfill, or may want to pick your own. The library should allow for such a use-case.
Maybe:
Either that or just do that by default.
I'd say most people who'd use this lib would have some way of dealing with polyfills. 🤷♂️