Replies: 2 comments 2 replies
-
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. |
Beta Was this translation helpful? Give feedback.
2 replies
-
The core team decided to go with this direction. We will remove the native binaries for
for the first step |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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
providesnative
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.
@swc/core
attempts to@swc/wasm
if native bindings are not able to be loaded@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#38883Beta Was this translation helpful? Give feedback.
All reactions