SWC plugin registry

Recently, I've been preoccupied with Wasm plugin compatibility issues in swc. I realized that backward compatibility would be difficult to achieve right now, so I decided to create a plugin registry that I had been putting off.

The first thing that determines if a Wasm plugin and host runtime are compatible is the version of swc_core. The version of swc_core used by the host and the Wasm plugin must be in the same range, but previously, these ranges were only documented, making it overly complicated for users to figure out which version of the plugin they should use.

It was also quite annoying for me, as the official SWC npm package (@swc/core) and the latest version of next.js often had different plugin versions supported by the latest version, which was problematic.

So, I decided to create a plugin registry. As a first step, I entered the data of compatible swc_core versions into the DB as static data. I named the model Compat Range. Then, I wrote a script to determine which version of swc_core each package can run SWC Wasm plugins, such as @swc/core, next.js, and rspack, uses. By cloning the repo and traversing all the git tags to find the dependency versions, I was able to put all the versions of swc_core that each version uses into the DB.

From this point on, I was able to do package name + version => swc_core version => Compat Range. But I wanted to include a link in the error message for swc_plugin_runner that would open the page for that Compat Range directly, so I scraped all the versions of swc_plugin_runner, swc_core, and put these crates from the crates.io index into the DB. Compat Range can now be found by swc_plugin_runner version, so I included the version information in the error message for swc_plugin_runner and put a link directly to the Compat Range page.

Now I'm thinking about how to include the version data of the swc_core used by the Wasm plugin in the Compat Range. This would allow the Compat Range page that `swc_plugin_runner` shows when a compatibility issue pops up to also show which version of the Wasm plugin is compatible with the runtime the user is using.

However, since Wasm plugins are mostly small projects, some don't use git tags, so using git tags was not an option. Even the official plugins the SWC project team maintains don't use git tags. So, I decided to traverse the entire git log.

It's a bit complicated.

1. Write down the repository URL and the names of the npm packages in a yaml file.

2. Make a git clone of the source code.

3. Check out the first commit.

4. Advance the commits one by one, looking for all package.json files and see if there is a package.json file for the SWC Wasm plugin.

5. If it does, treat that commit as a “deploy” commit.

6. Once we've traversed to the most recent commit, we cache the information we found.

7. Now that you have a list of “deployment” commits, traverse through them to find the Cargo.lock file.

   1. If the repository root has a Cargo.lock file, use it via git show.

   2. If not, check out that commit and look for all files named Cargo.lock in that repository.

8. If there is only one Cargo.lock file, or if all Cargo.lock files have the same swc_core version, use that version.

9. Cache the commit => the swc_core version map.

I did this because when a new version of the plugin is released, we only need to check the newly added commits. For reference, the source code is publicly available at https://github.com/swc-project/crawl-core-version.

I haven't put the Wasm plugins' versions on the website yet, but I'll do that tomorrow, and it shouldn't take long. In the meantime, I apologize for making you worry about the swc_core version. That shouldn't be the case now. We won't be able to fix the compatibility issues anytime soon, but we'll do our best to ensure you can use the Wasm plugins without too much trouble.