-
-
Notifications
You must be signed in to change notification settings - Fork 69
Resolve error: Failed to load native binding #446
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
Comments
https://yarnpkg.com/configuration/yarnrc?#supportedArchitectures yarn config set supportedArchitectures.cpu "wasm32"
yarn add -D @unrs/resolver-binding-wasm32-wasi
yarn config remove supportedArchitectures.cpu |
@JounQin It is probably the fault of both yarn and napi-rs, not providing enough information. Yarn should automatically detect the current system architecture and provide a warning where no suitable optional dependency was installed. napi-rs, on the other hand, should provide the current arch of the system, the variants already installed, and what is missing, in the error message (or |
Thank you for the prompt reply! I had to upgrade from Yarn 1.x to 4.x (with corepack), and then have the following
This then behaves nicely with the
And now vscode is working again and linting happily. Thank you |
@almunnings Maybe you can help to raise an issue to https://github.com/yarnpkg/berry
It's already there: https://github.com/unrs/unrs-resolver/blob/116035dd1b6ede33dac7236e91b0e21de837569a/napi/index.js#L372 Close as out of scope for now. |
Since upgrading past 3.8.7 the native binding has broken our workflow.
We use a container to install node and node dependencies and compile code, and then the local vscode does the linting locally.
Forgive me I am not an expert in eslint or node.
Container = linux node 20
Host = macos with vscode
With
@typescript-eslint/parser
andprojectService: true
- this tool chain is now unusable. We are unable to lint code and have it installed in a controlled environment.I attempted the suggested workarounds of
NAPI_RS_FORCE_WASI=true yarn add @unrs/resolver-binding-wasm32-wasi
but that won't install on an arm64 processor.Our only solution is to downgrade to
3.8.7
to avoid interruption.Is there a solution out there for me to compile within a container and lint locally? (I'd think this is fairly common practice for some websites.)
I'd need a way to optionally choose to not use the urns/resolver binary, or to optionally choose a binary based on some other factor. Or ideally a fallback is available somehow if the binary is unusable?
The text was updated successfully, but these errors were encountered: