Previously, developers using Wasm plugins often had to update them with each new release of @swc/core to ensure compatibility. This created friction, added maintenance overhead, and could disrupt development workflows.

Thanks to the introduction of a stable Application Binary Interface (ABI), this is no longer the case. A Wasm plugin compiled against v1.15.0 will now work seamlessly with future versions of SWC. This change dramatically improves stability and reduces the maintenance burden for both plugin authors and end-users.

This significant achievement was made possible by the incredible work on PR #11198. We want to extend our heartfelt gratitude to quininer on Github and the rspack team for their pivotal contributions and dedication.

This enhancement will directly improve the developer experience for everyone using the SWC project, as well as for users of downstream projects such as rspack and next.js.

Upgrade to v1.15.0 today and enjoy a more stable and seamless plugin experience!

Note: Still, some changes are not backward-compatible, but it’s now much easier to avoid a breaking chnage and we will.

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.

Bugfixes

ES parser

• https://github.com/swc-project/swc/pull/8332

ES codegen

• https://github.com/swc-project/swc/pull/8346

• https://github.com/swc-project/swc/pull/8351

ES: fixer pass

• https://github.com/swc-project/swc/pull/8357

ES: decorators pass

• https://github.com/swc-project/swc/pull/8320

ES: jsx pass

• https://github.com/swc-project/swc/pull/8339

• https://github.com/swc-project/swc/pull/8318

ES: renamer pass

• https://github.com/swc-project/swc/pull/8327

ES Minifier

• https://github.com/swc-project/swc/pull/8342

Note: v1.3.98 is skipped because CI failed, and we want to keep git tags immutable.

This is a very large release. So please check the links above.

This patch is mostly about the performance improvement.

Bugfix: ascii_only: false

• PR: https://github.com/swc-project/swc/pull/8217

Performance improvements

hstr instead of string-cache

• PR: https://github.com/swc-project/swc/issues/8126

hstr is a new string interning library designed for the Rust-side compilers. This is designed to avoid costly operations like strcmp as much as possible.

I'll write a detailed post about it in the near future.

Parser trivial optimizations

Removal of Rc::clone

• PR: https://github.com/swc-project/swc/pull/8231

Removal of strcmp

• PR:https://github.com/swc-project/swc/pull/8223

Really trivial ones

• PR:https://github.com/swc-project/swc/pull/8224

Smarter lookup table

• PR:https://github.com/swc-project/swc/pull/8226

Minifier trivial optimizations

Removal of needless operations in the name mangler

• PR: https://github.com/swc-project/swc/pull/8222

Transform trivial optimizations

• PR: https://github.com/swc-project/swc/pull/8213

We want to improve the documentation, we want to provide more plugins, and we want to do community management as a team.

I started the SWC project by myself a long time ago, but SWC has already outgrown the size of one person. I am only able to maintain the SWC project now because of the help of many people.

The goal is to make SWC a project that is stable enough and supports a lot of use cases so that any company or organization can adopt it without too much worry. We will also be expanding its functionality further to match the name Speedy Web Compiler and its original goals.

SWC has implemented libraries for handling CSS, XML, and HTML, which are so high quality that they pass all web standards test cases except for the weird ones where the behavior is different in different browsers. We'll be making these modules available as npm packages as well. We'll also be implementing a semver solver to reduce compilation time for people using SWC on the Rust side.

It's a lot of work, but I'm not trying to do it all myself, so if you're interested, please reach out to me on Twitter @kdy1dev or at kdy.1997.dev@gmail.com.

Patches for transform()

Bugfixes

block-scoping

• PR: https://github.com/swc-project/swc/pull/8175

PURE comment of parameters pass

• PR: https://github.com/swc-project/swc/pull/8202

PURE comment of BytePos(0)

• PR: https://github.com/swc-project/swc/pull/8207

private properties with optional chaining

• PR: https://github.com/swc-project/swc/pull/8090

Debugging mode of JSX

• PR: https://github.com/swc-project/swc/pull/8212

Patches for minify()

Bugfixes

Analyzer refactoring

• PR: https://github.com/swc-project/swc/pull/8164

CVE Update

• PR: https://github.com/swc-project/swc/pull/8174

This does not apply to the most of the users because SWC is a compiler and the input to the hash function is quite restricted.

Minifier bugfix

• PR: https://github.com/swc-project/swc/pull/8168

Compat bugfix

• PR: https://github.com/swc-project/swc/pull/8172

Minifier bugfixes

There were a bunch of minifier bug fixes.

• https://github.com/swc-project/swc/pull/8128

• https://github.com/swc-project/swc/pull/8145

Minifier improvements

• https://github.com/swc-project/swc/pull/8109

• https://github.com/swc-project/swc/pull/8127

• https://github.com/swc-project/swc/pull/8152

Compat bugfixes

• https://github.com/swc-project/swc/pull/8158

Compat improvements

• https://github.com/swc-project/swc/pull/8097

• https://github.com/swc-project/swc/pull/8138

API Improvement

• https://github.com/swc-project/swc/pull/8163

Bugfixes for transpiler

await using

• PR: https://github.com/swc-project/swc/pull/8101

Helpers

• PR: https://github.com/swc-project/swc/pull/8076

Decorators

• PR: https://github.com/swc-project/swc/pull/8102

• PR: https://github.com/swc-project/swc/pull/8099

Shorthand

• PR: https://github.com/swc-project/swc/pull/8077

Bugfixes for minifier

Better support for keep_fnames

• PR: https://github.com/swc-project/swc/pull/8093

The inliner now aborts correctly if the option is enabled, and the inline source is a function to avoid name conflict.

# npm
npm i -D @swc/core@nightly
# yarn
yarn add -D @swc/core@nightly
# pnpm
pnpm i -D @swc/core@nightly

nightly builds are automatically published once per day, and we are going to prolong the release cycle of latest builds.

(Special thanks to GitHub and Microsoft, for sponsoring enormous amount of computing time for all OSS projects)

In the future, we are going to use this to improve the stability of @swc/core. The users can check if a newer version of @swc/core has a bug that can break their app, without building @swc/core by themselves. But this also applies to the core team. We are going to build a huge CI that runs periodically and check if the app breaks with the nightly version of @swc/core.

Honestly, I (DongYoon Kang ) wanted to add telemetry or automatic error reporting for unreachable!()s because they will help prioritize issues, but I think we will go with opt-in telemetry, even in case we add one.

Fixes for transpiler

Decorator

• PR: https://github.com/swc-project/swc/pull/8050

Module

• PR: https://github.com/swc-project/swc/pull/8048

Variable scoping

async/await

• PR: https://github.com/swc-project/swc/pull/8056

Explicit resource management

• PR: https://github.com/swc-project/swc/pull/8044

Experiment: @swc/minifier

We are experimenting with a smaller package, namely @swc/minifier. It only contains the code required for the minification of ECMAScript.

@swc/html & @swc/xml (future)

We will publish our HTML / XML processing module as npm packages soon.

Bugfixes

TypeScript

• https://github.com/swc-project/swc/pull/8029

• https://github.com/swc-project/swc/pull/8018

These are continuous works to fix regressions caused by the implementation.

ES Minifier

• https://github.com/swc-project/swc/pull/8036

ES Transpiler

Private field with optional chaining

• https://github.com/swc-project/swc/pull/8031

Decorators

• https://github.com/swc-project/swc/pull/8017

More conformance to ESM specification

• https://github.com/swc-project/swc/pull/8024

Fix for TypeScript regression of the previous version

• PR: https://github.com/swc-project/swc/pull/8008

• PR: https://github.com/swc-project/swc/pull/8012

As the previous version was a complete implementation of the TypeScript pass, it introduced a few bugs. And those are fixed right away.

Fix for codegen of optional chaining

• PR: https://github.com/swc-project/swc/pull/8005

The issue was about TypeScript type case, but the problem was the ES code generator not checking the base of OptChainExprs.

Fix for codegen of unicode surrogates

• PR: https://github.com/swc-project/swc/pull/7985

Personally, this is a type of coding I'm very vulnerable to, but I dit solve it well.

jsc.baseUrl now works without jsc.paths

• PR: https://github.com/swc-project/swc/pull/7998

Block-scoped functions are mostly preserved

• PR: https://github.com/swc-project/swc/pull/7975

TypeScript passes are reimplemented

• PR: https://github.com/swc-project/swc/pull/7202

Return of jsc.experimental.keepImportAssertions

• PR: https://github.com/swc-project/swc/pull/7995

To help ts-node users, I added an alias for an experimental option back.

@swc/counter : The download counter

• PR: https://github.com/swc-project/swc/pull/7991

If you are writing a tool that uses SWC under the hood (in runtime) and published to npm, please considering depending on @swc/counter

Fix for nullish coalescing

• PR: https://github.com/swc-project/swc/pull/7980

Previously SWC produced an invalid code if an arrow function is mixed with ?? operator.

Fix for minification of template literals

• PR: https://github.com/swc-project/swc/pull/7971

SWC minifier has multiple kinds of inliner, and one of them inlined variables into the template literals even though it shouldn't. It's now fixed.

Static-linked msvc runtime

• PR: https://github.com/swc-project/swc/pull/7965

This PR will make user without msvc runtime installed happy.

Preserve instead of panic for jsc.paths

• PR: https://github.com/swc-project/swc/pull/7955

SWC now preserves the original import specifier if the resolver for jsc.paths fails to resolve.

Private name & logical assignments

• PR: https://github.com/swc-project/swc/pull/7958

chrome 74 is a bizarre target because class_property is not required but logical_assignments is required.

This caused an issue to SWC, but it's now fixed.

minify() now support scripts

• PR: https://github.com/swc-project/swc/pull/7943

The JavaScript API of minify() had module: bool for a long time, but the swc minifier didn't respect it. It's now fixed, and it's now respected.

An option to configure module resolver

• PR: https://github.com/swc-project/swc/pull/7945

{
    "jsc": {
        "parser": {
            "syntax": "typescript"
        },
        "target": "es2020",
        "baseUrl": ".",
        "paths": {
            "@print/a": [
                "./packages/a/src/index.ts"
            ]
        }
    },
    "module": {
        "type": "commonjs",
        "resolveFully": true
    }
}

jsc.module.resolveFully is added to various module types to support resolving dependencies with /index.js included.

Optimization for optional chaining

• PR: https://github.com/swc-project/swc/pull/7933

Now the optional-chaining pass works just like pure_getters are enabled.

Optimization for static blocks

• PR: https://github.com/swc-project/swc/pull/7944

class Foo {
  static x = 1;
}

was compiled as, which is not ideal. It's now

class Foo {
}
Foo.x = 1;

Fix for generator

• PR: https://github.com/swc-project/swc/pull/7932

Fix for emitAssertForImportAttributes

• PR: https://github.com/swc-project/swc/pull/7936

This PR also adds format.emitAssertForImportAttributes to minify().

Fix for codegen

• PR: https://github.com/swc-project/swc/pull/7916

Now the leading comments are printed correctly.