tc39
Remove harmful stage 1 polyfill recommendation
It seems that this document is inadvertently recommending that folks publish polyfills in stage 1, which is incredibly dangerous for web compat, rather than in stage 3, which is the appropriate time.
This PR does not change any stage advancement criteria; in spec lingo, it is editorial, not normative.
Stage 1, or 2 at the latest, is an appropriate time to experiment with implementations. They just shouldn't be shipped.
Temporal has had a polyfill since long before it got to stage 3, and was very useful, for example.
Totally; which is why i changed it to "reference implementations" - essentially what I want to capture (and am open to suggestions) is that nobody should be shipping, or publishing, any code that modifies the environment until stage 3.
The word "polyfill" is synonymous for many with "published code that automatically modifies the environment", and thus that word shouldn't be used imo in a stage prior to 3.
Since the issue is deployment to production, perhaps “polyfill” in this pull request should be clarified to “experimental polyfill” (even if this is redundant, maximal clarity can be good).
The note could also be made beefier to explicitly warn: no proposal’s polyfill should ever be used in production code before it reaches Stage 3.
@js-choi i'd be content with that if we could include "published to npm" or similar as well.
Just interesting, how to experiment with a several early-stage proposals, how they work together, when you can't load polyfills of them from NPM or something like that -)
Existing proposals haven't had any difficulty doing so since this process's inception - if that becomes an obstacle in the future, that'd be a great thing to learn.
@ljharb you are deeply mistaken. The most of JS standard library features had feedback and changes on the early stages after experiments with polyfills.
That has not been my experience in the past 7 years; the useful early stage feedback has come from userland implementations that do not modify the global.
If you think so, that meant that you do not monitor the proposals for the past 7 years. For example, the latest presented @js-choi proposal - and you could see the same in most of the standard library proposals, and it's only from me - and from implementations, that modify the global.
One potential advantage of “reference implementation” over “polyfill” is that it would include syntax based proposals too.
@acutmore it also describes the polyfill.js file that appears in many older proposals, but is responsibly never published anywhere.
@zloirock and all of that feedback is helpful for stage 3, and won't come up in plenary until stage 3 advancement reviews, or stage 3 implementation feedback. So, thanks - and your feedback was helpful - but none of that feedback would be "too late" if it were provided during stage 3.
@ljharb without this feedback is impossible to write a proper spec text that's required for stage 2. Without this feedback is impossible to find conflicts with other proposals, that's required for the design of this proposal on the early stages. About what stage 3 do you say?
It's not required for stage 2 - which only requires initial spec text - it's required for stage 3, and spec reviewers handle that. If it could only be discovered by implementations, then that can safely come in during stage 3, as is happening now for current stage 3 proposals.
If you find value in implementing it sooner, great! None of that feedback comes from publishing it, only implementing it. I often author polyfills in early stages, with tests, for this purpose! However, I don't publish them - or even make them public on github - until the proper time.
Stage 3 is an almost complete feature and on this stage detected mainly web compatibility problems. Stage 3 is a flag that something should be implemented in JS engines, the changes after stage 3 will be breaking for engines and will cause more significant problems than early-stage polyfills.
None of that feedback comes from publishing it, only implementing it.
The feedback comes from experiments with published polyfills. You could find it in many proposals repos.
That has not been the case for Temporal (which has had extensive stage 3 changes), and was not the case for every other proposal I can recall, all of which we have both authored polyfills for.
Maybe because I still didn't make a polyfill for Temporal? -) If you can't remember other cases - it's just a problem with your memory or attentiveness.
Temporal had a polyfill, the entire time, and it failed to catch most of these issues - the problem there is that it's a large spec. Most proposals are small, and thus most of these kinds of issues are caught purely on review.
Temporal had a polyfill
I did not say otherwise.
failed to catch most of these issues ... most of these kinds of issues are caught purely on review
But not all.
However, why do we talk only about polyfills? Let's say the same about transpilers plugin and will propose Babel and TypeScript unpublish, for example, decorators or pipeline operator plugins - it's the same implementations as polyfills.
Because there's no risk to web compatibility from that, because transpilation is done prepublish. It's unique to API proposals - transpilers are only for syntax proposals.
because transpilation is done prepublish
Nope, not always. Now it's usual practice to transpile dependencies and publish not transpiled version of code.
In specific ecosystems, like RN and ember, that is true - but it is nowhere near common, usual, or advisable, and either way, that code would never land on the web untranspiled, so the risk isn't there.
So why do I commonly see such problems on NPM, why do I see that someone trying to transpile core-js and have circular dependencies because of this, why do I see published TS with decorators and many other cases?
I'm sure there are a number of cases where people do the wrong thing. That doesn't cause a web compat issue, because they can't deploy that code to the web, because it'd be a syntax error. The web compat issue is when you can deploy something that works, and the real proposal changes the functionality.
Is, for example, all Deno infrastructure based on TS with all published tools a wrong thing? Will, for example, updating of decorators proposal to the final version break existent and published TS? I see it more often than early-stage proposal polyfills usage in a wild.