[e_y_]

> Polyfills that don’t polyfill

This is what's sometimes called a "ponyfill". The idea is to avoid messing with global scope (monkeypatching), which could be problematic if you have multiple polyfills for the same API or polyfills that don't perfectly match the native behavior.

This can be a good thing in some situations, but in general it's probably best to leave polyfill decisions to the bundler so you can decide which browsers you want to support. Or even produce multiple versions, a lightweight one for modern browsers and one with tons of polyfills that gets served to ancient ones.

[mhagemeister]

Author here.

Good point. Agree that the ideal scenario would be that the end user (or the tools they use) have the final say in which polyfills to load. It's a bit of a bummer that they are shipped as part of npm packages without an easy way to get rid of them.

I wonder if our industry will move to publishing the original source files to npm in the long run. Only the last piece of the chain, the developer using these dependencies, knows what their target environments are. So the bundler could then downlevel or polyfill the code for the specified targets.

[bsimpson]

I've always been kind of surprised that original sources aren't part of the NPM culture. For a long time, I included "typescript:main" in my package.jsons and configured my tools to prefer that to "main" (and now "module").

[MBCook]

I get not defining it yourself, especially if your polyfill is limited to the sliver of a feature you use, but why not check if the feature is there first?

Ok, maybe someone else monkeypatched it. But at least you’d end up using the native functionality if it was there.