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:

```bash
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:

```bash
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):

```bash
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:

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

```bash
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):

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

```bash
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:

```json
{
  "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`:

```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.