[RFC] AST compatibility of plugins

[kdy1]

Terms

normal ast: AST used by core transforms.
plugin ast: AST representation which can be passed to the dynamic library directly.

Requirements

These are what we want to achieve

• We need to pass AST to plugins and construct AST back from the output of plugins.
• We want to prevent adding fields/variants to ast being a breaking change.
• If possible, we want plugins to be fast.

Triage: serde

This is a good old technique for implementing plugin systems.

Previously serde_json is used to serialize/deserialize AST. This approach is easy to implement, but serialization and deserialization are costly enough to take more time than the plugin itself.

But adding fields or variants to AST nodes is breaking change. If a new plugin ignores fields, it will be simply removed from the output of the plugin.

Triage: Bridge-ast

This is the current design. This is conceptually very similar to serde-based one. Instead of representing AST in serialized form, we convert normal ast to plugin ast, which can be passed to dynamic libraries directly. Then dynamic library converts it back to normal ast.

But the ast compatibility issue is not solved. We can detect ast compatibility issue on load time, but we can't automatically fix it. All plugins will be broken when a field or variant is added.

Triage: Plugin-only ast (X)

This is based on prefix type of abi_stable. It didn't work, but idea is that we can make every type an opaque pointer. Accessing fields is done by calling methods on the pointer and it does not depend on the exact layout of ast types.

Problem is that abi_stable currently does not support mutating fields in prefix types.

Also, this requires lots of more work. We need to reimplement the visitor generator and we can't use exising utilities for swc_ecma_ast.

Finally, this makes all plugins slower. rustc optimize it well because there will be a lot of indirection. I expect it to be at least 2x slower. It's based on https://nullderef.com/blog/plugin-abi-stable/ and I expect much more slowdown like 5x to 20x, because we have lots of opaque types.

Ideas

Some ideas about this issue.

Idea: Add Unknown variant to enums and extra to structs

In this way, plugin will ignore extra fields and variants if they don't know the way to handle it.

The problems of this approach are that it will make the core slower, and target syntax in newly-added AST nodes cannot be handled.

e.g. If you use some feature in static blocks and if plugin is too old so it does not know static blocks, all ast nodes in static blocks will be simply ignored.

Idea: Just bump major version on breaking changes

This is too bad solution IMO, but may work.

Version history: https://crates.io/crates/swc_ecma_ast/versions

[hyf0]

What about the performance of Bridge-ast way?

Does this RFC show how to implement babel AST compatibility?

[kdy1]

Bridge AST is much fastter than serde_json.
You can see benchmark result at #2635 (comment)

[RiESAEX]

I can accept last idea if I just need to update my Cargo.toml and compile/publish it.

[kdy1]

For most of ast changes, it will be enough.
But the problem is plugins managed by other authors.

[esamattis]

Have other serialization formats than json been considered? For example msgpack should be somewhat faster but is it enough to make a meaningful difference?

[kdy1]

I tried some other formats, but I failed because many binary serializers did not support deserialize_any.

[hsiaosiyuan0]

Who are the target of this plugin system? Why the plugin cannot be implemented directly in Rust?

[kdy1]

Plugins will be written in rust. I'm not sure why you said

Why the plugin cannot be implemented directly in Rust?

[devongovett]

Problem is that abi_stable currently does not support mutating fields in prefix types.

Do you need mutation? Could the plugin API be like Fold where you return a new AST node? Then you could have a constructor function. When you add a field, I guess you'd need a new constructor that also accepts that new field while keeping the old one around. A bit messy but it might work.

Another wild idea: say you decide supporting all this ABI stable plugin system stuff is too much work, too slow, or causes too much perf regression in core. Have you thought of inverting the model? Rather than core loading a config, finding plugins, and calling them, the config could just be a small Rust program with a normal crate dependency on both SWC core's defaults and whatever plugins it wanted. You basically already have this, but with a much simpler API for the defaults and a standard API for plugins it might be simple enough for most people to understand even if they don't know Rust. And this avoids the ABI stability and plugin loading problems entirely. If you wanted, you could even have a config format in another language like JSON that you compile to a Rust program to make it even simpler.

[kdy1]

Do you need mutation? Could the plugin API be like Fold where you return a new AST node

To be exact, abi_stable does not support storing non-copy types. So we can't pass plugin ast back from plugin to core.

And about the wild idea, the problem is compile-time IMO. Compilation of node-swc takes 20 min ~ 40 min, so I'm not sure it's feasible. But seems like a great idea, thanks!

[devongovett]

Ah seems like you'd need to make your own wrapper type then...

Compilation only takes that long if you are compiling for all platforms though. When building a custom plugin config, you'd only need to compile for the system you're running on which is much less. Perhaps you could also distribute precompiled libraries as well to speed that up so that users don't need to recompile all of SWC core... hmm that might have the same rustc versioning problems 😕

[kdy1]

Actually 20 min ~ 40 min is per-platform time.

[padmaia]

The compile time would only need to happen when the config changes though, right? People may prefer that tradeoff in order to have as fast as possible transformations.

Not sure if this is the right discussion to ask this, but would there be an install size difference using wasm or native plugins vs rust transforms?

[padmaia]

Also 20-40 minutes is time on CI. If you just wanted to try a new plugin locally just to test it out and you have a more powerful machine, its much faster. My first gen M1 mbp is less than 5 minutes cold build.

[kwonoj]

Overall this RFC is bit oudated as we are pushing forward wasm-based plugin. Abi_stable is no longer a concern at least. It doesn't mean this discussion itself is outdated though: we'll have one ast only (no plugin_ast) but it can have breaking changes which requires some release planning.

[kwonoj]

Having one ast or not doesn't seem to relavant to your question (at least in my understanding)

Given we choose wasm as runtime for the plugin at the moment, as long as author can generate wasm binary swc can load & run it should work. Our intent is keeping single method of running plugin under swc.

[kwonoj]

Just abother clarify this applies for swc in rust / node bindings both.

[kwonoj]

Tl: dr

• plugin will be wasm binary
• swc passes its ast (which possibly can have breaking changes though), no additional ast sets
• Single wasm binary plugin should work either swc runs in its rust binary / or via node.js bindings

[RiESAEX]

now, we only have the second question We want to prevent adding fields/variants to ast being a breaking change. to be solve right?

[kwonoj]

My understanding so far is, yes. There'll be some inevitable breaking changes, but I hope adding a new fields would be seamless to not to break existing plugin.