Replace `serde` with a custom serializer specialized for writing JSON.
`impl Serialize` -> `impl ESTree`. I've called it `ESTree` in case we
want to add e.g. `impl Babel` later on.
The main motivation is that with control of the serializer, we can make
it stateful, so we can extend it to, for example, omit TS fields based
on a flag. This is pretty much impossible with `serde`'s interface.
But a side-effect of the simpler implementation is that it's also more
performant.
The usage of `ESTree` trait is very similar to `serde::Serialize`. Main
differences:
* `serialize` method is infallible. Does not return a `Result`.
* `state = serializer.serialize_struct();` instead of `map =
serializer.serialize_map();`.
* `state.serialize_field(...)` instead of `map.serialize_entry(...)`.
* Struct keys must be strings, and JSON-safe (not including `"` or other
characters that require escaping in JSON).
This is a breaking change, as it's possible downstream consumers are
using `serde` to serialize our AST to other formats. I'd guess unlikely,
but possible. We can always implement `serde::Serialize` as well as
`ESTree` further down the line if there's a demand.
I (and mostly copilot) wrote `VisitMutModuleRecord` to visit all spans as I wasn't sure how `VisitMut` is generated. I'm looking into visit generator now if it's something I can do. Please let me know if manually writing it down is fine for now or I should try macro (or maybe a completely different approach).
- closes https://github.com/oxc-project/oxc/issues/9079
I'm still leaving an existing TODO for `module_record` and `errors` span not being converted as they won't cause an immediate issue, but I'll work on that shortly.
Add a "reviver" function to `JSON.parse` in NAPI parser module, to correctly set `value` field of `Literal`s for `RegExp`s and `BigInt`s.
Surprisingly, judging by a local run of NAPI parser benchmarks (added in #9045), this does not seem to hurt performance. In fact the benchmarks were showing a ~2% speed-up. That's clearly nonsense - just noise - but it does suggest at least that this isn't hurting performance significantly.
This crate will no longer be relevant after we export esm information
directly from the parser.
Besides, `ex-module-lexer`'s output data is too limited for plugin
authors to use.
- Added TypeScript annotation for `ParseResult.program`
- Modified the entrypoint for `oxc-parser` to allow wrapping the napi functions
- Updated `index.js` to parse the `program` string into a JSON object
- Updated tests
- Added a dependency on `@oxc/types`
overlookmotel