Fix field order for `TSTypeAssertion`. Move `type_annotation` to before `expression`, because it comes first in source:
```ts
// ___ expression
let foo = <number>bar;
// ^^^^^^^^ type_annotation
```
Fix field order for `TSNamedTupleMember`. Move `label` to before `element_type`, because it comes first in source:
```ts
type Foo = [first: string, second: number];
// label ^^^^^ ^^^^^^ element_type
```
Fix field order for `PropertyDefinition`. Move `type_annotation` to before `value`, because it comes first in source:
```ts
class C {
x: number = 123;
}
```
Fix field order for `NewExpression`. Move `type_arguments` to before `arguments`, because they come first in source:
```tsx
const foo = new Foo<T>(1, 2, 3);
```
Fix field order for `TaggedTemplateExpression`. Move `type_arguments` to before `quasi`, because they come first in source:
```ts
const foo = tag<T>`quasi`;
```
Fix field order for `JSXOpeningElement`. Move `type_arguments` to before `attributes`, because they come first in source:
```tsx
<Component<T> foo={123} />
```
In `AccessorProperty`, move `type_annotation` field to before `value`, because it appears first in AST.
```ts
class C {
accessor x: number = 123;
}
```
This also aligns with TS-ESLint's visitation order.
Part of #9705.
Recent changes in TS-ESLint made `TSMappedType`'s `optional` field default to `false` instead of `null`. Update our TS-ESTree AST to match it.
Add an `#[estree(prepend_to = ...)]` attribute to accompany `#[estree(append_to = ...)]`.
* `#[estree(prepend_to = target)]` prepends the field to *start* of the target field.
* `#[estree(append_to = target)]` appends the field to *end* of the target field.
This also allow both prepending *and* appending to the same field. e.g. combining `TSThisParameter`, `FormalParameter`s, and `BindingRestElement` into a single array.
Pure refactor. Replace `AppendTo` and `AppendToConcat` which are used in ESTree serializer to concatenate 2 fields with a more generalized `Concat2`, which performs both functions.
`Pattern` and other types in `oxc_regular_expression` are not part of ESTree AST. Don't implement `ESTree`, and don't generate raw transfer deserializers for these types. None of that code is actually used.
This reduces the scope of ESTree serialization.
`RegExpPattern` was an enum with `Raw`, `Invalid`, and `Pattern` variants. i.e. only the raw string *or* the `Pattern` could be stored, but not both.
This required complications in various places, because if the regexp has been parsed, in order to examine or print it, you have to either convert the `Pattern` back to a `String`, or rely on the `Span` and slice the source text.
The `Invalid` variant is not very useful. It's only created if `parse_regular_expression` option is enabled, in which case an error is reported from the parser anyway.
Instead, always store the pattern string as an `Atom`, and store the parsed pattern as `Option<Box<Pattern>>`.
This simplifies code in various places, and makes printing `RegExpLiteral`s faster in `oxc_codegen` when `parse_regular_expression` is enabled, because it can just print the pattern string, rather than converting a `Pattern` back to a `String`.
#10791 fixed the performance of `oxc-parser` NPM package by removing the reviver from `JSON.parse` call. However, it replaced it with a complete traversal of the AST on JS side to locate `Literal` nodes and update them.
Instead, generate a list of paths to `Literal` nodes needing fixing on Rust side in `ESTree` serializer.
e.g. for this program:
```js
123n;
foo(/xyz/);
```
the fix paths are:
```json
[
["body", 0, "expression"],
["body", 1, "expression", "arguments", 2]
]
```
Having the location of nodes which need updating reduces work on JS side, as no need to search the entire AST.
Running `pnpm run bench` (in `napi/parser`) locally shows between 8% and 15% speed-up from this change.
#10791 added 2 files `generated/visitor-keys.cjs` and `visitor-keys.mjs` to the NAPI package. When I amended the original PR, I forgot to update `package.json` to include them both in NPM package.
Follow-on after #10791, part of #10783.
In the fixup visitor, replace `visitNode` with a more specialized
`transformNode` function. The difference is that `transformNode` doesn't
need to be passed `fn` as 2nd param.
Also, move the check for whether a node is a `Literal` into
`transformNode` to avoid the cost of a function call for every node
(most of which are not `Literal`s).
Running benchmarks locally (`pnpm run bench` in `napi/parser`), I'm
seeing a 2%-3% speed-up.
Fixes#10783
This requires having a list of ~135 nodes with their non primitive keys.
Technically this list could be generated alongside the raw deserializer
but I don't know this code enough to do it.
I've chosen to inline visitor keys to avoid adding [3
dependencies](https://pkg-size.dev/@typescript-eslint%2Fvisitor-keys)
for that.
I didn't find how the main LICENCE was injected during the publish so I
couldn't append the bundled LICENSES and choose to use `@licence`
comments with links
---------
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
It seems odd for `TSMappedTypeModifierOperator` to have a `None` variant. It's more conventional to represent "doesn't exist" as `Option::None`.
Remove the `TSMappedTypeModifierOperator::None` variant, and use `Option<TSMappedTypeModifierOperator>` instead of `TSMappedTypeModifierOperator`.
Both are the same to the compiler due to the niche optimization on `Option` (`Option<TSMappedTypeModifierOperator>` is 1 byte), but it just seems more logical to me this way.
Also an unrelated change: Shorten code in codegen and formatter.
Use the support for `#[estree(via = ...)]` on fieldless enum variants added in #10746 to remove custom serializer for `TSMappedTypeModifierOperator`. This serializer can now be auto-generated.
Does not effect output, only simplifies how it's generated.
Don't eagerly load raw transfer deserializer code. These files are large and will take JS engine some time to parse. Instead, `require` the appropriate deserializer lazily, when it's first needed.
For the majority of users who aren't using raw transfer (almost everyone, as it's currently behind an experimental option), avoid loading this code entirely.
Pure refactor. Move generated deserializer files for `napi/parser` into a `generated/deserialize` directory. This is to make room for more generated files (e.g. visitor, more specialized deserializers), without the number of file in root of the package exploding.
In ESTree (plain ESTree for JS i.e. Acorn), a hashbang is recorded as a line comment. Follow that behavior in our ESTree AST.
In TS-ESTree, hashbangs are ignored. That's not how it looks in AST explorer, because there's some post-processing going on, but `@typescript-eslint/parser` itself ignores hashbangs. So only add the comment in ESTree AST (not TS-ESTree AST).
More info on this rather confusing subtlety: https://github.com/typescript-eslint/typescript-eslint/issues/6500
The tests for ensuring field order is the same between JSON-based transfer and raw transfer were not working correctly. Fix them. Thankfully they all still pass!
Only VariableDeclaration, FunctionDeclaration and ClassDeclaration were
considered when collecting named export declarations for the module
record. Now the parser also considers TSTypeAliasDeclaration,
TSInterfaceDeclaration, TSEnumDeclaration, TSImportEqualsDeclaration and
TSModuleDeclaration named export declarations of the module.
Maybe the other `decl.declaration.is_typescript_syntax()` check in
`module_record.rs` also needs to be removed?
Closes#10318Closes#10556
Part of #9705.
TS-ESLint parser represents `X.Y` in `class C implements X.Y {}` as a `MemberExpression`, whereas in our AST it's a `TSQualifiedName`. Convert to `MemberExpression` in TS-ESTree AST.
Part of #9705.
TS-ESTree presents a `TSTypeName` which is an identifier `this` as a `ThisExpression`.
e.g. `type T = typeof this;` or `type T = typeof this.foo;`
Refactor `wrap.cjs` and `wrap.mjs` in `napi/parser` package.
* Update outdated comments.
* Move JSON transform function to top level to avoid creating a new closure each time `jsonParseAst` is called.
* Make the 2 files as similar as possible so it's easier to keep them both in sync.
Part of #9705.
Our AST represents `module X.Y.Z {}` as 3 x nested `TSModuleDeclaration`s. TS-ESTree represents it as a single `TSModuleDeclaration`, with a nested tree of `TSQualifiedName`s as `id`.
Additionally, TS-ESTree skips the `body` field if the module declaration has no body e.g. `module "foo";`.
Align our TS-ESTree AST with these oddities.
Follow-on after #10534. Fix the raw deser implementation for
`FormalParameter` to handle `TSParameterProperty`.
This involves moving some of the logic into a converter for
`FormalParameter`, instead of doing it all in `FormalParameters`
converter.
overlookmotel