esbuild: "The package "esbuild-linux-64" could not be found, and is needed by esbuild."

For anyone else like the OP who is using SvelteKit + Vite and also deploying on Vercel, I solved the following error simply by deleting package-lock.json and adding it to .gitignore

failed to load config from /vercel/path0/vite.config.ts
--
error during build:
Error: The package "@esbuild/linux-x64" could not be found, and is needed by esbuild.
 
If you are installing esbuild with npm, make sure that you don't specify the
"--no-optional" or "--omit=optional" flags. The "optionalDependencies" feature
of "package.json" is used by esbuild to install the correct binary executable
for your current platform.
at generateBinPath (/vercel/path0/node_modules/esbuild/lib/main.js:1840:15)
at esbuildCommandAndArgs (/vercel/path0/node_modules/esbuild/lib/main.js:1907:33)
at ensureServiceIsRunning (/vercel/path0/node_modules/esbuild/lib/main.js:2072:25)
at build (/vercel/path0/node_modules/esbuild/lib/main.js:1963:26)
at bundleConfigFile (file:///vercel/path0/node_modules/vite/dist/node/chunks/dep-6305614c.js:63019:26)
at loadConfigFromFile (file:///vercel/path0/node_modules/vite/dist/node/chunks/dep-6305614c.js:62995:31)
at resolveConfig (file:///vercel/path0/node_modules/vite/dist/node/chunks/dep-6305614c.js:62617:34)
at doBuild (file:///vercel/path0/node_modules/vite/dist/node/chunks/dep-6305614c.js:45474:26)
at build (file:///vercel/path0/node_modules/vite/dist/node/chunks/dep-6305614c.js:45463:22)
at CAC.<anonymous> (file:///vercel/path0/node_modules/vite/dist/node/cli.js:808:15)
Error: Command "npm run build" exited with 1

I’m going to try improving the error message in the situation where you have installed esbuild for a different platform than the one you’re currently on. The error message I added looks like this:

$ ./node_modules/.bin/esbuild
./node_modules/esbuild/bin/esbuild:106
          throw new Error(`
          ^

Error:
You installed esbuild on 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-arm64" package is present but this platform
needs the "esbuild-darwin-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 which has built-in support for installing a package on multiple
platforms simultaneously.

If you are installing with yarn, you can try listing both this platform and the
other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
Keep in mind that this means multiple copies of esbuild will be present.

Another alternative is to use the "esbuild-wasm" package instead, which works
the same way on all platforms. But it comes with a heavy performance cost and
can sometimes be 10x slower than the "esbuild" package, so you may also not
want to do that.

    at generateBinPath (./node_modules/esbuild/bin/esbuild:106:17)
    at Object.<anonymous> (./node_modules/esbuild/bin/esbuild:161:39)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47

Edit: And it’s also now documented on the website too: https://esbuild.github.io/getting-started/#simultaneous-platforms

This error suddenly started consistently happening to me in Netlify deploys using Vite without me having made any config or dependency changes.

Re-generating package-lock.json fixed it, and I have no idea why 🤷

edit Here’s a full command since I keep coming back here:

rm -rf node_modules && rm package-lock.json && npm i

# in a mono-repo, make sure to remove each package's node_modules directory as well:
rm -rf node_modules && rm -rf packages/*/node_modules && rm package-lock.json && npm i

This happened to me because I had --ignore-scripts on my npm command

FWIW we had the same issue with yarn 2 version berry. Since with Yarn 2, you can use zero installs which makes you commit the .yarn/cache folder (which is similar to node_modules).

Turns out adding this to our .yarnrc.yml file solved it as described here (tailor to what architecture you want to support): https://yarnpkg.com/configuration/yarnrc#supportedArchitectures

supportedArchitectures:
  os:
    - "current"
    - "darwin"
    - "linux"
    - "win32"

  cpu:
    - "current"
    - "x86"
    - "x64"
    - "arm64"
    - "ia32"

I noticed this issue when I ran an npm prune locally.

I’m on Windows, so the prune removed the cross platform packages from my package-lock.json. Then when the project was installed/built in GitHub actions (running on Linux) the build blew up because the linux binaries were missing.

Removing my node_modules, deleting package-lock.json and re-installing the dependency got everything working for me.

If you run into this issue, look at the diff of the package-lock.json compared to the last time the build worked and also check if you are building on a different OS than you updated the package-lock.json on.

I’m getting the same error when running esbuild on Vercel in a serverless function. In vercel/vercel#7287 I linked to my repository along with the deployment showing the error, but the complication is that the problem isn’t happening locally, only in the deployment, so I’m not sure where it goes wrong and how to go about debugging it. It’s probably a question for them, but I thought that cross-linking this issue couldn’t hurt.

Just adding our experience here…

We have a shared volume containing the node_modules from our developer’s mac machines to our numerous linux Docker containers. We can run the install from inside the containers to bypass this, but it’s prohibitively slow due to the size of the containers compared to the host machine.

It runs fine on the few non-mac machines we have which are both running linux.

Unfortunately the outputted suggestion for the additions to .yarnrc.yml doesn’t work either, as Yarn stubbornly will continue to detect the platform and not link the supportedArchitectures which are not in the current architecture/platform:

esbuild-linux-64@npm:0.14.14 The linux-x64 architecture is incompatible with this module, link skipped.

Yarn Classic used to have the option to pass the --ignore-engines flag which likely would have been a nice workaround, but in Yarn 2 this is deprecated, and I have not found another way to bypass the platform checks in Yarn 2.

This has just started destroying my vercel builds in a project that has worked for years. Very surprising and hard to solve as removing package-lock.json and the node_modules folder has not helped.

Edit: After another try it works.

Thank you for the quick response.

I deleted package-lock.json on a MacOS and a Linux machine, then ran npm install on both (npm version 9.2.0). I got 2 radically different lock files, which really puzzled me.

When I looked at the diff, I saw something very strange however. One of the lock files had:

"node_modules/esbuild": {	
      "version": "0.15.18",	
      "resolved": "https://registry.npmjs.org/esbuild/-/esbuild-0.15.18.tgz",	
      "integrity": "sha512-x/R72SmW3sSFRm5zrrIjAhCeQSAWoni3CmHEqfQrZIQTM3lVCdehdwuIqaOtfC2slvpdlLa62GYoN8SxT23m6Q==",	
      "hasInstallScript": true,	
      "bin": {	
        "esbuild": "bin/esbuild"	
      },	
      "engines": {	
        "node": ">=12"	
      },	
      "optionalDependencies": {	
        "@esbuild/android-arm": "0.15.18",	
        "@esbuild/linux-loong64": "0.15.18",	
        "esbuild-android-64": "0.15.18",	
        "esbuild-android-arm64": "0.15.18",	
        "esbuild-darwin-64": "0.15.18",	
        "esbuild-darwin-arm64": "0.15.18",	
        "esbuild-freebsd-64": "0.15.18",	
        "esbuild-freebsd-arm64": "0.15.18",	
        "esbuild-linux-32": "0.15.18",	
        "esbuild-linux-64": "0.15.18",	
        "esbuild-linux-arm": "0.15.18",	
        "esbuild-linux-arm64": "0.15.18",	
        "esbuild-linux-mips64le": "0.15.18",	
        "esbuild-linux-ppc64le": "0.15.18",	
        "esbuild-linux-riscv64": "0.15.18",	
        "esbuild-linux-s390x": "0.15.18",	
        "esbuild-netbsd-64": "0.15.18",	
        "esbuild-openbsd-64": "0.15.18",	
        "esbuild-sunos-64": "0.15.18",	
        "esbuild-windows-32": "0.15.18",	
        "esbuild-windows-64": "0.15.18",	
        "esbuild-windows-arm64": "0.15.18"	
      }	
    },	
    "node_modules/esbuild-darwin-arm64": {	
      "version": "0.15.18",	
      "resolved": "https://registry.npmjs.org/esbuild-darwin-arm64/-/esbuild-darwin-arm64-0.15.18.tgz",	
      "integrity": "sha512-tKPSxcTJ5OmNb1btVikATJ8NftlyNlc8BVNtyT/UAr62JFOhwHlnoPrhYWz09akBLHI9nElFVfWSTSRsrZiDUA==",	
      "cpu": [	
        "arm64"	
      ],	
      "optional": true,	
      "os": [	
        "darwin"	
      ],	
      "engines": {	
        "node": ">=12"

even though the package.json specified "esbuild": "^0.16.17",. The linux one did not contain this. Very strange.

I then decided to fully delete the node_modules folder on both machines and npm cache clean -f, then run npm install again.

This time, the listing of esbuild-darwin-arm64 was gone, and the lock files were identical.

Not sure I understand why the generation of package-lock.json depends on either, but that might be a question for the npm team.

Thank you for a fantastic package, and my apologies for wasting your time.

@james-innes’s workaround works great, but the real question is…

Why is esbuild adding the platform-specific package to package-lock.json? Isn’t package-lock.json supposed to be version-controlled, and hence supposed to be platform-independent?

If I’m on MacOS, and my colleague is on Windows, we will be generating different package-lock.json files, and our CI system, which might be some flavor of Linux, won’t run npm ci because the wrong platform-specific version of esbuild is getting installed.

Is there any way to avoid the platform-specific esbuild package from ending up in package-lock.json in the first place?

I’m geting this error in linux based docker image. Even after npm i esbuild-linux-64

I simply had to delete the node_modules folder and reinstall

Specifically the “esbuild-linux-arm64” package is present but this platform needs the “esbuild-darwin-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.

That sounds rather wrong.

AFAIK no one in the world copies the “node_modules” directory (!!!)

What people often do (especially in CI/CD) is to rely on package_lock.json (which is, in this scenario, commited to git) to avoid running “npm install” and doing instead “npm ci” (the description above seem to confuse these two very different commands)

“npm ci” respects the concrete dependencies listed in package_lock.json, while “npm install” recomputes them. The advantages of “npm ci” are speed and reproducibility. And it’s the normal way to do automated deploys in dockerized instances.

To anyone who wants to fix this, but does not want to remove --ignore-scripts for all packages, Running npm install esbuild after npm ci --ignore-scripts fixes the issue.

Two options that works on gitlab’s docker compose (node:20-buster)

№1

    # Build frontend
    - rm -rf node_modules/.cache/
    - npm install
    - npm i @esbuild/linux-x64 --save-dev
    - npm run test:unit
    - npm run build

№2

    # Build frontend
    - rm -rf node_modules
    - npm install
    - npm run test:unit
    - npm run build

@cobyrne09 This is the issue we are running into now. Did you ever find a solution?

I copied the built module from inside the container into the .yarn directory then referenced it like so in my package.json.

 "esbuild": "0.14.14",
 "esbuild-linux-64": "file:./.yarn/esbuild-linux-64",

Thank you @evanw , installing node through nvm instead of the installer from the site did the trick 👍🏻

I’m going to close this issue because it has been marked as unactionable for a while and specific steps to reproduce the issue from scratch haven’t been provided. This issue can definitely be reproduced by copying a node_modules folder from one OS to another without reinstalling, but your not supposed to do that. There should now be a specific error message when that happens with workarounds and workarounds are also described on the website. It’s unclear if this is what’s happening in all of these cases or if something is going on in other cases, but we won’t know unless specific reproduction steps are provided for the other cases. I think these are probably best filed as new issues instead.

I created the most basic setup I could here: https://github.com/andyburke/esbuild-bug-linux-mac

I’ll try to ask a colleague with a mac to pull and test it to see if they can repro the problem. If anyone here has a mac, maybe they could try as well.