Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sebastianrath opened this issue Aug 24, 2022 · 63 comments
Labels

Comments

@sebastianrath
Copy link

sebastianrath commented Aug 24, 2022

Describe the bug

Hi there,

I am using @swc/core to speedup the execution of my test suite with avajs/ava.

System info:
Ubuntu 20.04.1 (VM via parallels 18 on a Mac Mini Intel)
node 16.15.0

During npm run test I receive the following error, and I am not sure how to resolve the issue.

/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/transpilers/swc.ts:262
      throw new Error(
            ^
Error: @swc/core threw an error when attempting to validate swc compiler options.
You may be using an old version of swc which does not support the options used by ts-node.
Try upgrading to the latest version of swc.
Error message from swc:
Bindings not found
    at createVariant (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/transpilers/swc.ts:262:13)
    at createSwcOptions (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/transpilers/swc.ts:211:25)
    at create (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/transpilers/swc.ts:56:41)
    at createTranspiler (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/index.ts:784:16)
    at createTranspileOnlyGetOutputFunction (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/index.ts:1341:28)
    at createFromPreloadedConfig (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/index.ts:1404:34)
    at create (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/index.ts:624:10)
    at register (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/index.ts:591:15)
    at Object.registerAndCreateEsmHooks (/home/st/actions-runner/_work/snow/snow/node_modules/ts-node/src/esm.ts:116:34)
    at file:///home/st/actions-runner/_work/snow/snow/node_modules/ts-node/esm.mjs:8:7
   test/1.sys.test.ts exited with a non-zero exit code: 1

Input code

No response

Config

Snippet of tsconfig.json config:

  "ts-node": {
    "swc": true
  },

Playground link

No response

Expected behavior

Successful execution of npm run test.

Actual behavior

No response

Version

v1.2.241

Additional context

No response

@kdy1
Copy link
Member

kdy1 commented Aug 24, 2022

Which os/cpu are you using?

@kdy1
Copy link
Member

kdy1 commented Aug 24, 2022

Also, did you use something like --skip-optional or --ignore-scripts?

@sebastianrath
Copy link
Author

Thanks for the quick reply! I added more information under System Info. No --skip-optional nor --ignore-scripts is used.

Also for completeness, here is the definition of npm run test in package.json:

"test": "nyc --reporter=html --reporter=lcov --reporter=text ava"

@sebastianrath
Copy link
Author

sebastianrath commented Aug 24, 2022

Quick update, the same project/commit successfully built on the same machine (also Parallels) under Windows. Updating to swc/core@1.42.0works now also under Linux. Could the error come back or did the latest version fix something that could explain the issue on Linux?

@kdy1
Copy link
Member

kdy1 commented Aug 24, 2022

Did you share the project directory? You should install on target platform unless you are overriding npm config

@ejkg
Copy link

ejkg commented Aug 31, 2022

I was able to reproduce this issue with my Apollo Federation Gateway running in a Node docker container. I can provide the Dockerfile.

FROM node:17.3
WORKDIR /app
ENV NODE_ENV=dev
ENV ZIPKIN=http://localhost:9411
EXPOSE 4000
COPY . .
CMD ["yarn", "run", "dev"]

Also important to note is that I'm not experiencing this issue when I run this directly on my machine.
macOS 12.5.1, Apple Silicon M1
node 17.3.1

encountered this error on docker run my-image:1.0

$ docker run my-image:1.0
yarn run v1.22.17

$ ts-node src/index.ts
/app/node_modules/ts-node/src/transpilers/swc.ts:262
      throw new Error(
            ^
Error: @swc/core threw an error when attempting to validate swc compiler options.
You may be using an old version of swc which does not support the options used by ts-node.
Try upgrading to the latest version of swc.
Error message from swc:
Bindings not found
    at createVariant (/app/node_modules/ts-node/src/transpilers/swc.ts:262:13)
    at createSwcOptions (/app/node_modules/ts-node/src/transpilers/swc.ts:211:25)
    at create (/app/node_modules/ts-node/src/transpilers/swc.ts:56:41)
    at createTranspiler (/app/node_modules/ts-node/src/index.ts:784:16)
    at createTranspileOnlyGetOutputFunction (/app/node_modules/ts-node/src/index.ts:1341:28)
    at createFromPreloadedConfig (/app/node_modules/ts-node/src/index.ts:1404:34)
    at phase4 (/app/node_modules/ts-node/src/bin.ts:543:44)
    at bootstrap (/app/node_modules/ts-node/src/bin.ts:95:10)
    at main (/app/node_modules/ts-node/src/bin.ts:55:10)
    at Object.<anonymous> (/app/node_modules/ts-node/src/bin.ts:800:3)
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
error Command failed with exit code 1.

fwiw I'm running this

    "@swc/core": "^1.2.245",
    "@swc/helpers": "^0.4.8",

@Bluzzi
Copy link

Bluzzi commented Sep 5, 2022

I have the same problem, I can't start my project at all with Docker/TS-Node/SWC

@RiESAEX
Copy link
Contributor

RiESAEX commented Sep 5, 2022

Can you try to reinstall swc in your docker?

@Bluzzi
Copy link

Bluzzi commented Sep 5, 2022

That's what I am doing

Dockerfile:

FROM node:16.16-alpine

WORKDIR /app

COPY package*.json ./
RUN npm install
COPY . .

CMD npm run start

.dockerignore:

node_modules

@swc-bot swc-bot added the Stale label Sep 10, 2022
@swc-bot
Copy link
Collaborator

swc-bot commented Sep 11, 2022

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.

@swc-bot swc-bot closed this as completed Sep 11, 2022
@Bluzzi
Copy link

Bluzzi commented Sep 12, 2022

This issue is still valid

@btecu
Copy link

btecu commented Sep 15, 2022

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)

@swc-bot swc-bot added the Stale label Sep 20, 2022
@swc-bot
Copy link
Collaborator

swc-bot commented Sep 22, 2022

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.

@swc-bot swc-bot closed this as completed Sep 22, 2022
@btecu
Copy link

btecu commented Sep 22, 2022

The issue is still valid.

@kwonoj kwonoj reopened this Sep 22, 2022
@kwonoj
Copy link
Member

kwonoj commented Sep 22, 2022

Not sure why bot aggressively marks this one 🤔

@jgujgu
Copy link

jgujgu commented Oct 3, 2022

@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!

@btecu
Copy link

btecu commented Oct 3, 2022

Thanks @jgujgu. Is there anything for npm?

@kwonoj
Copy link
Member

kwonoj commented May 17, 2023

I'm not saying it's uncommon to share project across different platform users, saying there are some constraint of actions we can take. As said, we are open to accept fix / suggestions but afaik there is no clear win to any paths we can take.

@DaSchTour
Copy link

I think that the approach how bindings are handled is not compatible to package-lock.json and npm ci.
When installing (generating package-lock) on one OS and running the CI task on another OS by using npm ci this will always fail because the wrong bindings are persisted in the package-lock.

Or maybe it's because swc doesn't use the expected postinstall scripts or so that would work with the recommended approach when using private repositories on a CI like described in this documentation: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#use-private-packages

In short when using npm ci --ignore-scripts for security reasons swc doesn't setup properly when running npm rebuild && npm run prepare --if-present afterwards.

@DzmVasileusky
Copy link

We switched to pnpm, it is not only faster it also doesn't have this issue as well as issues with legacy peer dependencies in lock file

@moltar
Copy link

moltar commented Jun 8, 2023

Having the same issue. The only solution is to completely nuke the nvm (fnm) Node environment, and the local node_modules and do a full re-install. Seems like something gets written into the global scope, that has an effect on this?

@moltar
Copy link

moltar commented Jun 8, 2023

Never mind, just did it again without node (nvm) nuking, just node_modules and it worked.

For us, the cause of this misalignment, I think, is Renovate Bot. Every time it updates a dep, and I do a pull, then the breakage will occur.

@SkyaTura
Copy link

SkyaTura commented Jul 3, 2023

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...

@SkyaTura
Copy link

SkyaTura commented Jul 5, 2023

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

@jaybe78

This comment has been minimized.

@swc-project swc-project temporarily blocked jaybe78 Jul 24, 2023
@jaybe78

This comment was marked as spam.

@kdy1
Copy link
Member

kdy1 commented Jul 25, 2023

@jaybe78

This comment was marked as spam.

@kdy1
Copy link
Member

kdy1 commented Jul 25, 2023

@jaybe78 This is not a bug of swc

@littleski
Copy link

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.

@pcdevil
Copy link

pcdevil commented Jul 26, 2023

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!

@kanocarra
Copy link

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!!

@bodinsamuel
Copy link

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

@svargas-dev
Copy link

svargas-dev commented Sep 12, 2023

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:
TypeStrong/ts-node#2059
TypeStrong/ts-node#2056

@corazon-roto
Copy link

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

@MohitOru
Copy link

just clear node_modules files and do npm install

nmanu1 added a commit to yext/search-ui-react that referenced this issue Feb 20, 2024
The following changes were made to support React 18:
- Updated `react` and `react-dom` dev dependency versions from 17.0.2 to 18.2.0
- Updated peer dependencies to allow React 18
- Updated `react-collapsed` from v3.6.0 to v4.1.2 which supports React 18
- Copied `@reach/auto-id`'s `useId` hook  with minor modifications from https://github.com/reach/reach-ui/blob/dev/packages/auto-id/src/reach-auto-id.ts. Because the peer dependencies of that library don't allow React 18, we weren't able to install it directly anymore. This `useId` hook uses React 18's  `useId` hook if it's present and otherwise falls back to custom logic for React 16 and 17.
- Added a new `renderPin` prop to `MapboxMap` to allows React 18 users to render custom JSX into the DOM node for the marker element. This gets around the issue of having to call `createRoot` from `react-dom/client` in `MapboxMap`. This was causing issues on React 16/17 sites because Vite and Webpack were unable to determine that the dynamic import of `react-dom/client` wouldn't be reachable, and tried to resolve the package unsuccessfully. Rather than force existing consumers of the repo to update their bundler config to exclude `react-dom/client`, we provide this optional prop to React 18 users if they want to use React 18 features in their custom pin component, or if they don't want to get the console warning about using `ReactDOM.render` if they use the `PinComponent` prop.

To support testing in React 18:
- We are now fetching TextEncoder from utils when setting up the test environment because the new react-dom does not have it
- `@testing-library/react-hooks` doesn't support React 18 and it's functionality has now been added to `@testing-library/react` in v14. Because of this, `@testing-library/react` was upgraded to v14.2.1, which only supports React 18, and `@testing-library/react-hooks` was removed from the dev dependencies. The GitHub workflow for testing React 16 and 17 was updated to manually downgrade `@testing-library/react` to v12 and install `@testing-library/react-hooks`. Custom logic is added so that if `@testing-library/react-hooks` is installed, it's `renderHook` method is used (i.e. React 16/17), and otherwise the `renderHook` method from `@testing-library/react` is used (React 18).

J=BACK-2911, BACK-2923
TEST=auto, manual

Updated the test-site to use the new React 18 app initialization and tested all updated components manually to ensure they're not broken. Did a local npm pack of the repo and successfully used it in Pages repos with React 17 and 18.

Some updates were also made to clean up our tests:
- Upgraded `@testing-library/user-event` from v13.5.0 to v14.5.2, which makes async calls, so we no longer need `waitFor`. As part of this change, we started getting some new console errors when trying to navigate in tests by clicking links. This is because navigation is not defined in the jest jsdom environment. A util function was added to mock the console to remove these errors.
- Updated the GitHub test workflow for React 16 and 17 to manually install optional swc libraries because the post install script doesn't seem to run properly after we install specific versions of react-related packages. More info at swc-project/swc#5616 (comment)

---------

Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Nidhi Manu <nmanu@yext.com>
@jwalton
Copy link

jwalton commented Feb 23, 2024

I worked around this with:

npm install --save-dev @swc/core@1.3.2 @swc/cli@0.1.57
npm install @swc/helpers@0.4.11

These are pretty old versions - there's likely newer ones that work, I just grabbed these from a project where I didn't have this issue.

@throrin19
Copy link

I'm having same issue using @swc/core:1.5.2

@tfeltwell
Copy link

tfeltwell commented May 7, 2024

@throrin19 there is a deprecation warning against 1.5.2 now: @swc/core@1.5.2: Mac OS installation is broken. Upgrading to 1.5.3 fixes the issue for me (Bindings not found when running jest)

@kdy1
Copy link
Member

kdy1 commented May 10, 2024

Can someone provide a minimal repro?

@bediu
Copy link

bediu commented May 23, 2024

@kdy1

The installation always fails on certain servers. For me specifically, in the cheap ones running on vCPUs.

uname -m output is aarch64

lscpu output is:

Architecture:           aarch64
  CPU op-mode(s):       32-bit, 64-bit
  Byte Order:           Little Endian
CPU(s):                 4
  On-line CPU(s) list:  0-3
Vendor ID:              ARM
  Model name:           Neoverse-N1
    Model:              1
    Thread(s) per core: 1
    Core(s) per socket: 4
    Socket(s):          1
    Stepping:           r3p1
    BogoMIPS:           50.00
    Flags:              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

Let me know if I can provide you with nay additional information.

(We have resorted to version locking swc manually in our monorepo for now, which isn't good. )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests