new: Start on es2022 preset. Implement class-static-block.
#3033
Conversation
github-actions
bot
added
A-ast
| for stmt in &body.body { | ||
| if stmt.is_private() { | ||
| if let Some(name) = stmt.property_key().and_then(|k| k.private_name()) { | ||
| private_names.insert(name.as_str().to_owned()); |
There was a problem hiding this comment.
I tried to avoid the clones but kept running into borrow issues.
|
|
||
| // We special-case the single expression case to avoid the iife, | ||
| // since it's common. | ||
| let replacement = if block.body.len() == 1 |
There was a problem hiding this comment.
Is there a better way to handle this branch??
CodSpeed Performance ReportMerging #3033 will not alter performanceComparing Summary
|
| // NOTE: all callbacks must run in order. | ||
| x0_typescript: TypeScript<'a>, | ||
| x1_react: React<'a>, | ||
| // x2_decorators, | ||
| x3_es2022: Es2022<'a>, |
There was a problem hiding this comment.
Ordering here is weird. When we add es2024, es2025, etc, all the numbers will shift. We probably need a different ordering system.
|
Thank you for the PR! Are we settled on everything, or should we refactor the current a bit more before getting into other presets? |
|
@Boshen We're still waiting on that PR to see if it's viable. |
|
I think we should support |
I agree that, compared to the es version, preset-env is more practical. Moreover, I believe that the current Babel implementation completely separates env from the es version. However, when we implement the code logic, it is OK to classify according to the ES version; this is merely a matter of code organization. |
|
Yes this is purely for organization. It's also required for tranformers to run in the correct order: typescript -> react -> es2024 -> es2022 -> es2021, etc. And furthermore, transforms within a preset must also be ran in a specific order. |
I got it, Thanks! |
No description provided.