-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Only allow ECMAScript stage 4 features #22083
Conversation
I don't know if using stage-3 was expected. If it was, this PR can be safely closed and I'm sorry for the noise! However, by looking at this PR, I gather that the common thinking was that we can write code in stage-4 (that is enabled by our babel preset). |
Size Change: 0 B Total Size: 835 kB ℹ️ View Unchanged
|
Can you clarify how this actually works? i.e. Where do we configure Stage 4? |
We don't do it directly, but by virtue of using the preset-env. The preset enables all approved changes (stage-4) as stated in the docs (which are a bit lacking on specifics, they only say "preset that allows you to use the latest JavaScript"). While reviewing the docgen PR I've actually looked at the babel-preset code and this is what I've found:
This is all a bit convoluted but that's what I understand we do by using the preset-env. |
I've traced at least one case where we use syntax enabled by |
As far as I know, this code is run directly through Node and isn't polyfilled in any way. I guess it depends whether this support commitment extends beyond just "features we enable in the Babel configuration" and to also include "any code we write". |
As noted at #22030 (comment) , this should be considered a breaking change, both for |
As per this thread and this conversation we're going ahead with this. We'll wait to merge until the beginning of next week, so we have a full plugin cycle to uncover any unexpected errors and bundle it with the CSS support as well. |
do we add the CHANGELOG comment here or is it enough to mark this PR as a breaking change and we take care of that in the package release? cc @gziolo |
We should include a note in the CHANGELOG to let people know what has changed so they know how to fix it. In fact, the PR that @aduth is working on #22030 includes a note of how such language features (plugins) can be enabled so it might be a good idea to cross-link. |
e04af5f
to
510a899
Compare
@gziolo I've added a changelog comment here as well, so this is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that the change is applied to @wordpress/babel-preset-default
– we should call it a braking change there in the first place. In @wordpress/scripts
we probably should only mention that @wordpress/babel-preset
had breaking changes that might affect those who use the default config. It's tricky :)
510a899
to
b7a5592
Compare
Added a note in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you 💯
Turns out I misunderstood what I thought that the flag includes proposals that are past-stage-4, approved and scheduled for the next standard release, but the standard is not published yet. But the meaning is different: it includes also stage-3 proposals which are implemented and shipping in browsers and are not yet stable. Every proposal needs the experience and feedback from actual implementation and real-world usage before advancing to stage-4 and beyond. I had a chat with Till Schneidereit from Mozilla, who explained these details to me, and recommended against any blanket rule that includes stage-3 proposals, and recommended using them in production only if there is a real, sizable benefit. |
@jsnajdr, we get the same explanation in #22030 (comment) from Henry Zhu from Babel :) |
While reviewing #22030 (comment), I realized that we're allowing to write code in ECMAScript stage-3 and above, and not only stage-4.
This was enabled by switching on
shippedProposals
in #19065. At the time, it looks like the thought was that enabling this, will make babel to list feature proposals that were part of stage-4 and already shipped by browsers. However,shippedProposals
may add stage-3 as per the docs. For example, at the moment, we could theoretically use the numeric separator feature, which is on stage-3.This disables the
shippedProposals
so we only use stage-4.