transform: accept AST input

[lukeed]

Ideally I should be able to run code thru oxc-parser, apply my own visitors, and then pass the resulting AST to oxc-transform to write/convert to string.

Plugging into the existing oxc-transform output options is fine to start, but I think oxc-transform should also allow TS/TSX final output. This wouldn’t be the default/common case, but it’d allow for a wider range of transformations without the need for an oxc-writer standalone module that (hypothetically) would just stringify an AST. (This would be kinda silly since that functionality would already be included in oxc-transform, which would mean projects using oxc-parser, oxc-transformer, and oxc-writer include the parsing and writing Rust code twice)

[Dunqing]

Currently, this is impossible now because we don't have a deserializer to convert ESTree AST back to Rust AST, which is an important part of what we support the transformer plugin in the future, but now we don't have a clear plan for that.

[overlookmotel]

Just to expand on what Dunqing has said, it is very much a target for us to allow passing ASTs as inputs/outputs for all components of Oxc in JS-side APIs.

However, as you're no doubt aware, the big problem is the performance hit of JS-Rust interop when passing large complex objects between the 2 "worlds". Serializing+deserializing JSON is a massive cost which dwarfs the cost of doing the actual work (parsing, transforming etc) on Rust side.

We have a solution for this problem, but it's somewhat experimental and unstable at present. Our focus right now is on firming it up to be production-grade for transferring AST in Rust -> JS direction. We're also building a prototype for linter plugins written in JS that uses this mechanism, and will prove its correctness and performance in a real-world setting.

After that, we'll implement transferring ASTs in the opposite direction (JS -> Rust), at which point APIs to do what you're asking for will become possible. However, it's trickier than Rust -> JS direction for various reasons.

So... TLDR... this is very much on our roadmap, but I'm sorry to say it will likely be many months before it's ready.

Hope the additional context is useful.

---

Plugging into the existing oxc-transform output options is fine to start, but I think oxc-transform should also allow TS/TSX final output. This wouldn’t be the default/common case, but it’d allow for a wider range of transformations without the need for an oxc-writer standalone module that (hypothetically) would just stringify an AST. (This would be kinda silly since that functionality would already be included in oxc-transform, which would mean projects using oxc-parser, oxc-transformer, and oxc-writer include the parsing and writing Rust code twice)

If I understand correctly, this is an independent feature from your first point.

This would be somewhat difficult to implement, because downlevelling transforms currently rely on that they're working on a JS-only AST. It's not impossible to change that, but difficult.

Can I ask, do you have a concrete use case for that?

[lukeed]

Thank you both for the added context~!

@Boshen suggested I take a look around and I saw that there's currently no way to ingest an AST. That said, I think it'd be a perf cost worth paying (at least for now, until the optimizations arrive) as it'd allow users to get an AST in JS world (via oxc or another estree impl), apply whatever transformations/rewrites, and then send the finalized AST back into Rust world to write the final AST to disk. This still is a big win as it prevents the need to reimplement or bring a bunch of JS tooling to do the AST-to-string step, which is much slower than Rust (I assume even with serde cost) and worse, is incorrect or incompletely implements all the ESTree (with TS) nodes. Re-using the OXC stringifier would have the added benefit of already applying oxc-formatter-type output options in the same pass.

In the many months into the future, this approach can still coexist with the improved API that exposes some JS plugins that work on the AST (like oxc-linter). The above would still be the variable/flexible entryway into the oxc ecosystem with the known perf hit. But it's good to still have a passageway into the oxc umbrella for those starting with acorn-based workflows.

---

Yes this probably is a second request, sorry. A few cases come to mind:

1. preserving JSX (see esbuild) -> leave JSX alone so that other tools or runtimes (eg bun) can transpile it later w/ desired settings
2. Generating DTS files from TS -- pipelines already exist (including oxc-transform, ofc) but I may generate an AST that produces some TS code and then it'd be more efficient to stringify the AST, then mutate it & serialize again. May be a contrived example, but every AST node should have a 1:1 string representation.
3. Generating TS from a DTS. Lets say my program takes some stub definition and generates/expands it into code.

Anything on the left has an equal AST on the right, but I should be able to paste an AST on the right and get a (bonus: formatted) string on the left.

[Boshen]

Close as stale and not planned for now.