Should ponyfills really never "use the native API"?

[lgarron]

I recently added a link to this repo at the top of https://github.com/lgarron/clipboard-polyfill
I held off for a long time and still feel a bit uncomfortable about this, because this repo explicitly states:

Ponyfills should never use the native API, even if available, as it might have slightly different behavior between environments, which can cause bugs.

This is impossible for certain kinds of "ponyfills" such as mine. It also applies to various other projects like https://github.com/chrisguttandin/standardized-audio-context

As new browsers implement new unprefixed standards, they will often have differences in behaviour (or outright bugs) and it can be useful to have libraries that specifically address "different behavior between environments". In this case, it's often impossible to implement such a library without relying on the parts that browsers have already implemented. Even when it is possible to avoid, it often saves code size to use the browser implementation when possible.

For such libraries, I still find it useful to distinguish between "avoids modifying built-in behaviour and makes itself available as a separate module" vs. "tries to monkey-patch the built-in behaviour directly".

• Do you consider such libraries to be ponyfills even if they call the native API under the hood?
• If so, would you be open to removing or revising the sentence quoted above? (e.g. "Ponyfills should never use the native API
• If not, what word would you recommend for describing such a library / would you advise against linking to this repo?

[sindresorhus]

Yeah, I guess we could change the wording to "should strive to not use the native API" and then list some cases where it would be valid. The point I was trying to put across was in the general case. There are always exceptions. PR welcome if you want to improve the wording.