swc: @swc/core threw an error when attempting to validate swc compiler options.

adding the core modules as optional dependencies for the project fixed the error for me:

npm install --save-optional \
    "@swc/core-darwin-arm64" \
    "@swc/core-darwin-x64" \
    "@swc/core-linux-arm-gnueabihf" \
    "@swc/core-linux-arm64-gnu" \
    "@swc/core-linux-arm64-musl" \
    "@swc/core-linux-x64-gnu" \
    "@swc/core-linux-x64-musl" \
    "@swc/core-win32-arm64-msvc" \
    "@swc/core-win32-ia32-msvc" \
    "@swc/core-win32-x64-msvc"

you can also filter out the list of packages in case you are certain what is the OS / architecture of your development computer and the CI.

hope this helps for others until the issue is resolved!

I’m having this issue re-appear with @swc/core@1.3.83 (and @swc/core@1.3.84) on Linux (Debian 12) with a mono repo using npm. If I explicitly install @swc/core@1.3.83 (or @swc/core@latest) in my workspace it doesn’t work but explicitly installing the previous version i.e., npm -w=backend i -D @swc/core@1.3.82, is a good workaround for now.

EDIT: My issue is actually a ts-node issue. See: https://github.com/TypeStrong/ts-node/issues/2059 https://github.com/TypeStrong/ts-node/issues/2056

I’ve ran into similar issue with a bit uncommon setup, but maybe this will help shed some light.

I have a working setup on local node 18, using yarn (on intel mac). I wanted to create a sample Dockerfile using npm, so I ran npm i locally to generate package-lock.json. Then docker build ran up to the build point where it failed on Fallback bindings does not support filesystem access.. When installing @swc/core and @swc-cli in the build step in the container again, it worked well.

Then I removed node_modules and package-lock.json on the host and ran npm i again to get a new package-lock.json. And with this new lock the whole build ran successfully.

old-package-lock.json.txt package-lock.json.txt

When compared, there are few @swc packages that didn’t get “locked” with existing node_modules.

So, maybe the “work-around” is to rm -rf node_modules && rm package-lock.json && npm i on the host?

Also, on host I have cli, core, core-darwin-x64 in node_modules/@swc. When I ran ls in the broken-build image, I got cli, core, wasm with the old-package-lock.json. With the new, working lock I have core-linux-x64-gnu and core-linux-x64-musl in there instead. Docker image is based on node:18-slim.

@btecu @Bluzzi My co-worker found a fix for this, inside .yarnrc.yml. Both of us are using M1 Pro MacBook Pros and his worked without this addition, but for some reason mine had the error throw new Error("Bindings not found");

The solution was to put - arm64 under cpu. Full output of .yarnrc.yml.

nodeLinker: node-modules

plugins:
  - path: .yarn/plugins/@yarnpkg/plugin-workspace-tools.cjs
    spec: "@yarnpkg/plugin-workspace-tools"

yarnPath: .yarn/releases/yarn-3.2.3.cjs

# This setting ensures we always install the Linux binaries when running `yarn install`. This is needed for running
# swc natively in Docker from a Mac host.
supportedArchitectures:
  os:
    - current
    - linux
  cpu:
    - current
    - x64
    - arm64
  libc:
    - current
    - glibc

I don’t know if it’ll solve your guy’s problems, but it did solve mine!

I’m also running into this issue after updating from node 14.17.1 to node 16.16.0 on a MBP 16 M1 Pro:

/Users/.../node_modules/@swc/core/index.js:250
        throw new Error("Bindings not found");
        ^

Error: Bindings not found
    at Compiler.transformSync (/Users/.../node_modules/@swc/core/index.js:250:15)
    at transformSync (/Users/.../node_modules/@swc/core/index.js:348:21)
    at transformSync (/Users/.../node_modules/@swc-node/core/index.ts:69:26)
    at compile (/Users/.../node_modules/@swc-node/register/register.ts:44:40)
    at exts (/Users/.../node_modules/@swc-node/register/register.ts:55:38)
    at Module._compile (/Users/.../node_modules/pirates/lib/index.js:130:29)
    at Module._extensions..js (node:internal/modules/cjs/loader:1180:10)
    at Object.newLoader [as .ts] (/Users/.../node_modules/pirates/lib/index.js:141:7)
    at Module.load (node:internal/modules/cjs/loader:1004:32)
    at Function.Module._load (node:internal/modules/cjs/loader:839:12)

This issue is still valid

I can work around this by simply yarn add -D @swc/core@latest.

What helped me in my npm monorepo:

1. npm uninstall all swc related packages
2. remove package-lock.json
3. remove all node_modules directories
4. npm install
5. npm install the swc related packages again

I was having the same issue Fallback bindings does not support filesystem access. when running in GitHub Actions.

@pcdevil 's response solved the issue - thanks!!

What have helped me

1. Create new clean project
2. manually install @swc/core of needed version there
3. manually copypaste core-darwin-x64 to node_modules/@swc

thanks @pcdevil that was the solution for me (when compiling react-email in docker)

Same problem. Runs fine on MacOS in local env and throws while building on Docker.

The workaround is use pnpm. It is not desired on our project but it passes…

Not sure why bot aggressively marks this one 🤔

I think there is a bug in the postinstall.sh script in the swc module. Somewhere, it “trash” the @swc/wasm module instead of adding it. the script however is discarded if @swc/wasm is added in the dependencies. What fixed it for me (in my dockers in CI), is to add the package in the dependencies. But looking at the comments, i think there is multiple issues listed here, so it may not fix for everyone.

I put it again here, in case it helps someone.

pnpm solved the build on CI, but my coworker is unable to run the project on Ubuntu (Node v18.16.0)

@kwonoj well, we are sharing project among people with MacOS, Windows, Ubuntu but this is a normal situation when repo has collaborators

this issue is annoying I have to install swc manually each time after npm i, does anybody found a way to fix it once for all?

What have helped me

1. Create new clean project
2. manually install @swc/core of needed version there
3. manually copypaste core-darwin-x64 to node_modules/@swc

Indeed this solution is working well when I run npx jest "file", btw installing @swc/core is enough and solves the problem, but I’m Interested if there are other dependencies that require it.

I have the same issue when I use Github action on @swc/core 1.3.44. I try to downgrade to @swc/core 1.3.39.The action work again.

What helped me in my npm monorepo:

1. npm uninstall all swc related packages
2. remove package-lock.json
3. remove all node_modules directories
4. npm install
5. npm install the swc related packages again

This is exactly what I did and it solved the issue.

I ran into a similar problem when running a build with SWC in GitHub actions (worked fine on my M1 mac).

The build would fail with Fallback bindings does not support filesystem access.

After upgrading @swc/cli to 0.1.62 and @swc/core to 1.3.39 the build executed again in my workflow.

@littleski I ran into the same problem and adding @swc/wasm solved it for me too…so yes, a bug in the post install maybe?

I think there is a bug in the postinstall.sh script in the swc module. Somewhere, it “trash” the @swc/wasm module instead of adding it. the script however is discarded if @swc/wasm is added in the dependencies. What fixed it for me (in my dockers in CI), is to add the package in the dependencies. But looking at the comments, i think there is multiple issues listed here, so it may not fix for everyone.

Hey buddy, I have encountered the same issue as you and have solved it, I would like to share my experience with you to see if it can help. Just a few days ago I was able to install Taro-cli without any issues, then after reinstalling the system, my project encountered the same error as yours. I searched for solutions in the Taro repository and the SWC repository, but there was no ready answer. However, they gave some directions to troubleshoot.So I tried switching the node version, package manager version and source, and Taro/cli version, but all failed. Finally, I debugged the source code with breakpoints, combined with my own experience, and found that the problem was related to the rust runtime environment, which needed to be installed. The specific installation method can be referred to the link below. https://blog.csdn.net/u011149152/article/details/123518465

This issue has been automatically closed because it received no activity for a month and had no reproduction to investigate. If you think this was closed by accident, please leave a comment. If you are running into a similar issue, please open a new issue with a reproduction. Thank you.