feat(@angular/build): migrate Angular Linker to oxc-parser and magic-string - #33625
feat(@angular/build): migrate Angular Linker to oxc-parser and magic-string#33625clydin wants to merge 1 commit into
Conversation
89f575b to
a1a721b
Compare
There was a problem hiding this comment.
Code Review
This pull request introduces a high-performance Angular partial declaration linker using oxc-parser and magic-string to replace the Babel-based linker. The review feedback highlights critical compatibility issues with the OXC AST structure. Specifically, oxc-parser does not export a Visitor class, requiring a custom recursive AST walker instead. Additionally, OXC AST node types differ from standard ESTree nodes: generic Literal nodes are represented as specific StringLiteral, NumericLiteral, BooleanLiteral, and NullLiteral nodes; identifiers are split into IdentifierReference and IdentifierName; and object properties are represented as ObjectProperty instead of Property.
JoostK
left a comment
There was a problem hiding this comment.
I've been wanting to experiment with this, so I'm excited to see this 🥳
|
|
||
| class InlineDeclarationScope implements DeclarationScope<unknown, unknown> { | ||
| getConstantScopeRef(): null { | ||
| return null; |
There was a problem hiding this comment.
This works, but has the downside of pushing the constant pool in a local IIFE for each declaration, instead of sharing a single pool per module. Especially for library FESMs I'd expect this to introduce a bit of code-size overhead (due to inability to share constants across declarations).
There was a problem hiding this comment.
There is the potential for the raw output sizes to be slightly larger. However, the over-the-wire (compressed) sizes should be nearly identical. The local IIFE also has DCE advantages since a single pass will remove the unused constants. Shared constants of a significant size are typically going to be rare as well.
| node: T, | ||
| _sourceMapRange: SourceMapRange | null, | ||
| ): T { | ||
| return node; |
There was a problem hiding this comment.
This probably means that compiled template code won't be mapped into its original external file mappings.
There was a problem hiding this comment.
Yes. However, vendor source maps are typically not enabled so there would be no effective loss for the common case. In a followup, we can add a segment-based string factory that could be enabled for vendor source map cases though.
There was a problem hiding this comment.
Yeah, this is fine as follow-up 👍
9118d3c to
b7fb852
Compare
…string This refactors the Angular linker processing in the ESBuild pipeline to use `oxc-parser` and `magic-string` instead of `@babel/core`. By using the lightweight AST and precise token spans provided by OXC, the linker is able to process partial declarations via targeted `magic-string` overwrites in-place. This removes the dependency on `@babel/core` and the linker Babel plugin, yielding faster build startup times and improved compilation performance.
b7fb852 to
7517eb6
Compare
This refactors the Angular linker processing in the ESBuild pipeline to use
oxc-parserandmagic-stringinstead of@babel/core.By using the lightweight AST and precise token spans provided by OXC, the linker is able to process partial declarations via targeted
magic-stringoverwrites in-place. This removes the dependency on@babel/coreand the linker Babel plugin, yielding faster build startup times and improved compilation performance.