Fallback bindings does not support filesystem access in Github Action #5837
Labels
Comments
|
Fallback binding doesn't support filesystem itself isn't a bug, but there's lacks of info what env action actually runs makes swc picks up fallback bindings. |
|
The GH action runs on |
|
ubuntu-latest supposed to work with native binaries. If you can't share the repo / or what's happening in the actions, unfortunately you may need to dig to figure out why native binaries are not being installed correctly as we do not have way to figure out those. |
Only if native binaries cannot be installed somehow at this moment. |
|
I checked the Do you have any advice on what I could do to debug this? |
|
Most straight forward debugging process is
as those are the conditions fallback bindings kick in if any of above fails. |
|
Here's the content of the ls -alR node_modules/@swcI noticed that locally on my mac m1 I have an additional: Are these the bindings? Any idea why they could be missing in the github action? |
|
Are you running codes in docker? |
|
I would think the github action runs in some kind of docker container Locally, I don't use docker |
No, not by default. Check your action config and remove docker if it's not explicitly required. Otherwise, this is dupe of #5616. I'll close this issue anyway since there's original issue can be tracked. |
|
https://gist.github.com/nephix/749cf7159478a59b37e6cbc4f235de7d that's our GH action, I don't think we explicitly require docker anywhere in other github actions, only for deployment |
|
No, you are: https://gist.github.com/nephix/749cf7159478a59b37e6cbc4f235de7d#file-gh-action-L13-L14
|
|
Ah ok, but funnily enough we compile the code in a docker container in AWS and that works without a problem |
@kwonoj Why would this matter if deps are also installed in the same container and therefore same OS? |
We do not know exactly why on certain cases npm fails to install its optional deps for the specific platform when it's inside of docker. That's the reason original issue #5616 is currently bit hanging. The way install optional deps for the swc is relying on npm's optional depedencies by specifying corresponding platforms, where swc does not controls its detection and installation. |
|
Btw I switched from Not ideal but at least a ✅ |
|
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Describe the bug
When I compile our project locally it works like a charm:
When I compile our project in a GitHub action using the same
npm run buildcommand it fails.Input code
No response
Config
{ "module": { "type": "commonjs", "ignoreDynamic": true }, "jsc": { "target": "es2018", "parser": { "syntax": "typescript", "dynamicImport": true, "decorators": true }, "paths": { "@app/*": ["./src/*"], "@test/*": ["./test/*"] }, "transform": { "legacyDecorator": true, "decoratorMetadata": true } }, "minify": false }Playground link
No response
Expected behavior
SWC compiles our code in a GitHub action
Actual behavior
In the Github Action I get
Version
"@swc/core": "^1.2.244"
Additional context
No response
The text was updated successfully, but these errors were encountered: