Reduce native binary target platform support

[kwonoj]

Status	Last Updated	Target version
Accepted	2022-011-2	TBD

Summary

This proposal describes a plan to reduce the number of native binary target @swc/core supports, falling back to @swc/wasm for those environments.

Motivation

SWC currently provides 2 different bindings to support various platforms / targets. @swc/core provides native bindings supported via node.js's napi, which have corresponding native binaries per each platform. Remaining unsupported platforms are required to use @swc/wasm instead, including non-native (Browser) environments.

Native platform expansion for @swc/core has been increased ad-hoc bases. In result, currently we have these 13 native bindings to be built per each release:

• core-win32-x64-msvc
• core-darwin-x64
• core-linux-x64-gnu
• core-linux-x64-musl
• core-freebsd-x64
• core-win32-ia32-msvc
• core-linux-arm64-gnu
• core-linux-arm-gnueabihf
• core-darwin-arm64
• core-android-arm64
• core-linux-arm64-musl
• core-win32-arm64-msvc
• core-android-arm-eabi

Which has become a notable bottleneck for daily dev workflow.

First, there are targets that require specific setups for its pipeline, mostly if the target is not commonly used, or it requires cross compiling. This cannot be easily reproducible & debuggable locally, and requires a certain amount of time to run CI for troubleshooting. Not only for general troubleshooting, this becomes a bottleneck for daily work since we need to spend a lot of time & resources for the CI jobs.

Secondly, those targets are commonly not supported by some core upstream features which we can't provide feature parity. For example, we are not able to provide wasm-based plugin features for some targets like android, i686, armv7.

Even with those caveats, actual gains are not huge. There are nearly no users are on certain platforms. (I hope if we could have telemetry in @swc/core itself and can share specific data, but that's entirely another story may involve lot more discussions probably)

For those reasons, this proposal suggests to @swc/core provides native bindings for these targets:

• core-win32-x64-msvc
• core-linux-x64-gnu
• core-linux-x64-musl
• core-linux-arm64-gnu
• core-linux-arm64-musl
• core-darwin-arm64
• core-darwin-x64

Note this is not a permanent decision. We'll occasionally evaluate surroundings, either add / remove necessary platform support if there are sufficient needs.

Detailed design

This is mostly about discontinuations and possible road forward is already prepared.

• By default, @swc/core attempts to @swc/wasm if native bindings are not able to be loaded
• In case of @swc/core internally not able to install @swc/wasm, upstream will try to fix - but also as a workaround user's package.json can install @swc/wasm side by side to @swc/core. Importing @swc/core will try to look for @swc/wasm.

Drawbacks

This can cause potential regressions for some users if fallback doesn't work as expected. We'll try to address those failures as quickly as we can.

Alternatives

The only possible alternative is to keep the current target as-is. But to do those, there should be some answers to the problems currently we're dealing with.

References (if exists)

next/swc have aligned changes vercel/next.js#38883

[kwonoj]

This is a topic core team members (of course including @kdy1 ) and few other interested parties have been discussed for some months & trying to collect some data to confirm the least used targets and I believe we are mostly agreed on the list of targets we'd like to keep support.

[Brooooooklyn]

should we also post this on twitter/reddit or some other social media to involve more of our users to discuss it?

[kwonoj]

The main problem is active user voice != actual numbers of users. For example, freebsd is quite popular in those places including SWC repo itself, but general usage is nearly non exist. There's no way to measure user numbers from user opinion.

If there are ways to solve existing problems with rust's compiler ecosystem and if someone provides a paved path for it, may worth to share. But afaik that's pretty much known, something we can't get easily similar to golang's support for cross compiling (and upstream feature support like wasm runtime for plugins).

[kdy1]

The core team decided to go with this direction.

We will remove the native binaries for

• freebsd
• android

for the first step