Wasm plugin stabilization

[kdy1]

What do you think about stabilizing the Wasm plugin as-is?

It does not have backward compatibility, but someone proposed stabilizing it as-is, and bump the major version of @swc/core each time Wasm plugin breaks.

Pros

• Version resolving of npm will work as expected so end-users of @swc/core (only) will not have to know about swc_core versions

Cons

• The major version will go up quite fast.
• Version management of Parcle / next.js / rspack cannot follow this.

[kdy1]

Alternatively, we can build a web app to list SWC plugins. This has been on my TODO list for a very long time, but I didn't have the resources (time) to implement it.

[chenjiahan]

What's the difference between this web app and awesome-swc?

[kdy1]

It stores the version information of swc_core of Wasm plugins and plugin runners like @swc/core, next and rspack.

awesome-swc does not have version data

[chenjiahan]

Considering that the SWC Wasm plugin breaks frequently, Rspack plans to release a minor version every time SWC contains an AST breaking change. (Rspack does not plan to release major versions frequently).

If SWC can reduce the frequency of breaking the Wasm plugin, it would be very helpful for downstream projects and users. 😄

[chenjiahan]

bump the major version of @swc/core each time Wasm plugin breaks.

Vote for this, swc_core has reached v0.100, it's time to follow semver

[hardfist]

I think @swc/core and swc_core should be treated the same(the difference is just js api and rust api), and bump major when wasm plugin breaks, and let the framework(rspack | nextjs | parcel) decide their own bump strategy

[RobinClowers]

I was very put off by the current situation where end users have to match swc_core versions manually. It sounds like this proposal would at least allow proper dependency tracking, which would make it easier, but still a headache. I think a much better solution would be to invest in a back compat story, but if that's going to take a long time, this seems like a reasonable improvement.

That said, please don't give up on backwards compatibility, that's the real solution to this problem, and it would make the project much easier to use outside of next or other meta frameworks.

[kdy1]

I left a question on Rust reddit. https://www.reddit.com/r/rust/comments/1eybm5d/question_for_serialization_deserialization/

Hi. I'm the author of the SWC project. We currently use rkyv for Wasm plugins. We pass serialized bytes to the Wasm plugin and deserialize them from the Wasm plugins, but it's not backward-compatible.

Most of the time, we only need to add fields to existing types. I don't want it to be a breaking change. I think what we need here is ignoring extra data (from a new version of host) and using a default value if when not existing.

Is there a serialization/deserialization library that supports it?

I'm even considiering mixing rmp_serde with rkyv - use rkyv if compatible and use rmp_serde if not compatible. Deos this sound viable?