Cannot find module @rollup/rollup-linux-x64-gnu (GLIBC version error)

When building a project that uses Vite or Rollup (common in modern JavaScript apps and WordPress theme builds), your build command may fail with an error like this:

Error: Cannot find module @rollup/rollup-linux-x64-gnu. npm has a bug related to optional dependencies (https://github.com/npm/cli/issues/4828). Please try `npm i` again after removing both package-lock.json and node_modules directory.

At first glance this looks like a package installation problem. Before you act on it, look further down the stack trace for the cause. If it reads something like:

Error: /usr/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by .../@rollup/rollup-linux-x64-gnu/rollup.linux-x64-gnu.node)

then the message about npm's optional-dependency bug is misleading. The native Rollup module installed correctly. It simply can't load, because it was compiled against a newer version of the system C library (glibc) than the build environment provides.

Why removing package-lock.json does not help

The advice printed in the error - delete package-lock.json and node_modules, then reinstall - fixes a genuine but different npm issue. When the underlying cause is a GLIBC_x.xx not found message, reinstalling changes nothing: the freshly installed binary still requires the same newer glibc.

Switching Node.js versions won't help either. glibc is part of the underlying operating system, not the Node.js runtime, so changing your Node version leaves it untouched.

You can check the glibc version available during your build by adding ldd --version as its own line at the start of your build command (each line in a build command runs in sequence, so keep it on a separate line from your install/build steps):

ldd --version
npm install
npm run build

How to fix it

Recent Rollup 4 releases ship prebuilt native binaries that require a newer glibc. The most reliable fix is to tell your package manager to use Rollup's official WebAssembly build instead, which contains no native binary and therefore has no glibc requirement.

Option 1 - Use the WebAssembly build of Rollup (recommended)

Most projects - including anything built with Vite - pull Rollup in indirectly (as a dependency of another package) rather than listing it themselves. For those, tell your package manager to substitute the WebAssembly build.

npm - add an overrides entry to the package.json of the project you're building, then reinstall:

{
  "overrides": {
    "rollup": "npm:@rollup/wasm-node@^4"
  }
}

npm install
npm run build

Yarn - use a resolutions entry instead, and reinstall with Yarn (an overrides/resolutions block only takes effect through the matching package manager):

{
  "resolutions": {
    "rollup": "npm:@rollup/wasm-node@^4"
  }
}

yarn install
yarn build

If your project lists rollup directly in its own dependencies or devDependencies, an npm overrides entry will be rejected with an EOVERRIDE error. In that case, don't add an override - change the direct dependency itself to point at the WebAssembly build:

{
  "devDependencies": {
    "rollup": "npm:@rollup/wasm-node@^4"
  }
}

The WebAssembly build is a drop-in replacement. Builds may be marginally slower, but they no longer depend on the system glibc version.

Option 2 - Pin an older Vite / Rollup

Vite 4 uses Rollup 3, which is written entirely in JavaScript and ships no native binaries, so it avoids the problem completely. If you aren't relying on features specific to Vite 5 or later, you can pin it in your package.json:

{
  "devDependencies": {
    "vite": "^4"
  }
}

Reinstall and build as usual afterwards.

Still stuck?

If your build keeps failing after trying one of the options above, email us at support@deployhq.com and include your build log. The cause section of the stack trace tells us exactly which library version is being requested, which makes it much quicker to pin down.

Before sending it, please redact anything sensitive - build logs can contain environment variable values, access tokens, credentials, or private URLs. Remove those and keep the surrounding error output intact so we can still see what failed.