Update babelParse to use legacy decorator syntax #21506
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes #21243
What I did
Set up 'legacy-decorator' syntax for babelParser, because it is the only available plugin that supports property decorators (at least, which does not throw an error), which are heavily used in Angular.
As noted here,
@babel/parser
does not support registering other plugins only the ones which are integrated into the core of@babel/parser
.The
legacy-decorator
plugin uses the originalStage 1
proposal. Whereas e.g. Typescript uses theStage 2
proposal (in Typescript 5.0, even the Stage 3.0 proposal).It seems that in Babel 8, the
@babel/plugin-proposal-decorators
get merged into@babel/parser
, which will very like supportparameter decorators
with the newest decorator Stage 3.0 proposal:Differences between the proposals
It is essential to know in which particular areas the proposals differ from each other and whether there are any differences by applying decorators by ignoring the internal implementations of decorators, because for AST parsing this is not relevant.
Differences between Stage 2 / 3 proposal:
Differences between Stage 1 / 2 proposal:
Differences between Typescript "experimental" decorators / Stage 2 decorators:
Impact evaluation:
Opting out for an older decorator proposal might introduce unforeseeable bugs. The babel parser might not be able to parse newer decorator proposal syntax and will likely throw an error.
Optional: Allow the user to overwrite the basic parsing settings
postcss-lit
has implemented the possibility to overwrite the default options, passed to the babel parser. Should we do this as well?!Alternative: Gently recover from "soft" errors.
We can pass the option
errorRecovery: true
to the@babel/parser
to continue parsing the code, if babel can recover from the error state. Then we don't have to opt-out to the olddecorators
proposal and we can still parse the AST without babel throwing a non-recoverable error.Mentionable resources
Checklist
MIGRATION.MD
Maintainers
make sure to add the
ci:merged
orci:daily
GH label to it.["cleanup", "BREAKING CHANGE", "feature request", "bug", "documentation", "maintenance", "dependencies", "other"]