SWCX (Native SWC binary) stablization plan

[kwonoj]

Status	Last Updated	Target version
In review		@swc/cli 2.0

Summary

This RFC attempts to propose promote SWCX, new CLI binary written in rust as official CLI for the SWC.

Motivation

After introducing experimental CLI binary #3859, general feedback was positive. There are some missing features, and some issues need to be fixed, but core features are working stable enough for the daily workflow.

By promoting native CLI as official, we can consolidate development activity in the single repo (SWC upstream) as well as issues and features to be implemented in a single, de facto implementation instead of trying to support in both packages.

Detailed design

Main problem need to be solved in here is mostly about the logistics. For the native CLI binary, there is a desire to use it without npm being involved. As far as I know, npm package’s bin property only allows to invoke JS file as entrypoint - so wrapping native binary as npm package requires spinning node.js process regardless. Since we’ll going to maintain @swc/cli this’ll stay anyway, but also there would be a way to install binaries without node / npm.

These are the distribution mechanisms proposed.

• Cargo install

This is currently working already, we’ll keep support it.

• GH release (All platforms)

When @swc/core publish gh action triggers, post CLI binary into GH release. A user who want to manually download, or some automatic download script will use this.

• Brew tap (Mac, Linux)

For the Mac / Linux installation we can create custom tap to download / install binaries from above GH release.

• Winget (Windows)

Windows does not have brew, use winget registry instead.

• @swc/cli (node.js)

Existing @swc/cli will have breaking changes, internally replace implementation to spawn native binary instead of current one.

I would consider this as minimal distrubition mechanism we’ll going to support. Most cases for the local / CI devs I expect to use brew / winget-like package manager approach, but if that’s not available user still have a fallback option. For the package manager perspective I do not expect we’ll expand to other managers, like snap / flatpak / or distro-specifics. Current release targets for the SWC are already large, and we have to minimize efforts for the release processes.

Drawbacks

We'll going to experience some transition period while new binary have some missing features to @swc/cli.

Alternatives

Unresolved questions

References (if exists)

#3859

[kdy1]

I love this idea.

[kwonoj]

I can start work on non-breaking changes first.

Where can I find how current binaries are being uploaded in each release (i.e https://github.com/swc-project/swc/releases/tag/v1.3.18)?

[kdy1]

cc @Brooooooklyn I think it's done by napi, right?

[Brooooooklyn]

Yes, it's uploaded by @napi-rs/cli

[kwonoj]

Where we do invoke it in the actions? I don't think napi-rs will allow to upload arbitrary binaries, so probably have to chain upload after napi-rs creates release & upload.

[Brooooooklyn]

in prepublishOnly script in package.json: https://github.com/swc-project/swc/blob/main/package.json#L56