You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried installing this application in my pi and this happened:
node:internal/modules/run_main:122
triggerUncaughtException(
^
Error [TransformError]:
You installed esbuild for another platform than the one you're currently using.
This won't work because esbuild is written with native code and needs to
install a platform-specific binary executable.
Specifically the "@esbuild/linux-x64" package is present but this platform
needs the "@esbuild/linux-arm64" package instead. People often get into this
situation by installing esbuild on Windows or macOS and copying "node_modules"
into a Docker image that runs Linux, or by copying "node_modules" between
Windows and WSL environments.
If you are installing with npm, you can try not copying the "node_modules"
directory when you copy the files over, and running "npm ci" or "npm install"
on the destination platform after the copy. Or you could consider using yarn
instead of npm which has built-in support for installing a package on multiple
platforms simultaneously.
Even if I generate my own node_modules then the make script cleans it up. I am very annoyed. Who gave this idea. How can we know if your cockpit application is injecting malicious scripts of not if we use your cockpit node_modules cache like this? Another problem is, each user would need to download packages for all cockpit projects when they only need one.
And it does not even work.
So, kindly remove this setup and make cockpit work on pi, thanks!
The text was updated successfully, but these errors were encountered:
node_modules being broken on ARM is already tracked in #609.
We track node_modules in git because running npm install is dangerous. Modules can have arbitrary post-install scripts , and that was already exploited several times in the wild, like here. So we only run npm i in a tightly isolated container, and commit the result to git for getting reproducibility and isolation.
How can we know if your cockpit application is injecting malicious scripts of not if we use your cockpit node_modules cache like this?
You can run npm i yourself and diff it with the git checkout.
You can run npm i yourself and diff it with the git checkout.
This even happens automatically in our reposchutz workflow -- if anyone sends a PR with a node_modules/ change that doesn't match package.json, the PR will be automatically blocked.
I tried installing this application in my pi and this happened:
Even if I generate my own
node_modules
then the make script cleans it up. I am very annoyed. Who gave this idea. How can we know if your cockpit application is injecting malicious scripts of not if we use your cockpitnode_modules
cache like this? Another problem is, each user would need to download packages for all cockpit projects when they only need one.And it does not even work.
So, kindly remove this setup and make cockpit work on pi, thanks!
The text was updated successfully, but these errors were encountered: