Polyfill needed

[mikesamuel]

Polyfills and the evolution of the Web has some advice

3 Advice for polyfill authors

...

3.1 Encapsulate as a module or UMD

...

3.3 Don't squat on proposed names in speculative polyfills

If a feature has not passed the tipping point, do not squat on the proposed or common name (whether it's a property of the global object or of a global constructor/prototype). Consider prefixing or changing the proposed name, or appending 'polyfill'. For example, if an upcoming feature is likely to be called window.Foo, consider attaching your polyfill to window.FutureFoo or window.FooPolyfill.

So creating a polyfill as an npm package would suffice, and it should not mutate Array regardless of the resolution to issue #7.

As Daniel mentioned, we probably need to distribute it alongside a babel plugin that collects hoisted template objects and registers them with a WeakSet.

[ljharb]

I use https://github.com/es-shims/es-shim-api for all my shims/polyfills, which allows for proper shimming but doesn’t do so by default.

[mikesamuel]

https://github.com/mikesamuel/is-template-object should provide something that is compatible with the es-shim-api requirements (see test) but will still need work as far as babel integration to be spec compliant around forgeries.

[mikesamuel]

@ljharb, What is needed above and beyond implementing es-shim-api?

[ljharb]

Just writing tests, I guess - the intention is that a compliant package a) has a consistent module interface, b) by default doesn't mutate the environment, c) can give you a "polyfill" in any environment, which is either the native method, or not, depending on how broken it is, and d) can self-install properly when requested explicitly.

[mikesamuel]

Closing. Any other requirements for the polyfill can be collected at its issue tracker.

[littledan]

I don't know about the details of es-shim, but I think it would be best to omit a "shimming" more until this "crosses the threshold".