What this usually means
This error class points to a build-time dependency Nuxt expects but cannot resolve. It's rarely just a missing npm install. Instead, the root cause often involves incorrect package versions, corrupted node_modules, orphaned lockfiles, case sensitivity issues between OSes, or wrong dependency declarations (like misplaced devDependencies or hoisted modules in a monorepo). Nuxt's SSR or custom module hooks can also reference packages not declared in the consuming package.json.
The first ten minutes — establish facts before touching code.
- 1Run `npm ls <missing-module>` or `yarn why <missing-module>` to see if the dependency is actually present or hoisted away.
- 2Delete both node_modules and lock files (`rm -rf node_modules package-lock.json yarn.lock`) then install clean.
- 3Check for typos or case mismatches in your import statements vs real file/folder names (especially on macOS vs Linux).
- 4Verify the module is in dependencies, not devDependencies, if it's needed at build/server runtime.
- 5If in a monorepo, check if the module is hoisted or mistakenly shadowed by another workspace.
- 6Look for custom Nuxt modules or plugins referencing missing packages in their hooks.
The specific files, logs, configs, and dashboards that usually own this bug.
- searchnuxt.config.js and any custom buildModules/plugins
- searchpackage.json dependencies and devDependencies
- searchnode_modules tree (`ls node_modules/<module>` or with tools like `tree`)
- searchThe lockfile: package-lock.json or yarn.lock (look for duplicate or missing entries)
- searchCI build logs for previous warnings about package resolutions
- searchWebpack trace output in the full stack trace
Practical causes, not theory. These are the things you will actually find.
- warningModule present in devDependencies instead of dependencies (SSRs need deps)
- warningCase mismatch between import path and filesystem (e.g. 'Foo.js' vs 'foo.js')
- warningYarn/npm caching stale modules despite reinstall
- warningMonorepo workspaces hoisting or de-duping dependencies away
- warningPartial lockfile updates after a bad merge, leading to mismatched packages
- warningNuxt module/plugin requiring a peer dependency that's missing
- warningPackage published with .npmignore or missing files in dist
Concrete fix directions. Pick the one that matches your root cause.
- buildMove package from devDependencies to dependencies if needed at runtime
- buildDelete node_modules and all lockfiles, then do a fresh install
- buildForce yarn/npm to resolve the correct version (use resolutions or pin exact versions)
- buildFix all import paths to match file/folder names exactly (especially on case-sensitive FS)
- buildAdd missing peer dependencies for any custom Nuxt modules/plugins
- buildIf in a monorepo, add dependency explicitly to the affected workspace's package.json
A fix you cannot prove is a guess. Close the loop.
- verifiedRun `nuxi build` or `nuxt build` with `--verbose` and see zero 'module not found' errors
- verifiedCI builds pass with a cold cache (simulate with `npm ci`)
- verifiedImport paths in editor match on-disk casing and autocomplete works
- verified`npm ls <module>` shows the dependency at the expected location
- verifiedSSR render works both locally and in production
- verifiedRunning with `NODE_ENV=production` still succeeds
Things that make this bug worse or harder to find.
- warningBlindly reinstalling node_modules without cleaning lockfiles
- warningAssuming devDependencies are always included in production/SSR
- warningIgnoring case sensitivity by only testing on macOS or Windows
- warningNot including custom modules’ dependencies in the main package.json
- warningAllowing lockfile merges with unresolved conflicts
- warningAssuming monorepo hoisting makes all modules globally available
Nuxt Build 'Module Not Found' in CI After Monorepo Refactor
Timeline
- 10:12PR merged updating dependencies in /packages/webapp
- 10:15CI fails with: 'Module not found: Can't resolve axios'
- 10:24Local build works; engineer suspects a caching issue
- 10:30Engineer runs `yarn why axios` and sees it's now only in the root package.json
- 10:37Adding axios to webapp's own dependencies, deleting lockfiles and node_modules
- 10:41CI passes; root cause confirmed as missing workspace-local dependency
I merged a PR that refactored our monorepo structure, moving most dependencies up to the root. Our webapp package had previously listed axios in its devDependencies and built fine both locally and in CI.
After the merge, CI started failing on `nuxi build` with a 'Module not found: Can't resolve axios' error. Local builds still worked because my dev environment had an old node_modules tree.
Running `yarn why axios` inside /packages/webapp showed it was only hoisted at the root. The fix was to add axios to the webapp's own dependencies, clean all node_modules and lockfiles, and rerun the build. Lesson: Nuxt SSR always needs runtime dependencies declared locally in the consuming package.json.
Root cause
axios had been hoisted to the root workspace and was not present in the webapp's own dependencies, breaking SSR in CI.
The fix
Explicitly add axios to webapp's dependencies, clean all installs, and update the lockfile.
The lesson
With SSR frameworks like Nuxt in monorepos, always declare build/runtime dependencies in the local package.json, not just the workspace root.
Nuxt's SSR engine builds server bundles that execute in production. Its runtime must resolve modules from dependencies, not devDependencies, which are omitted in production installs (especially in CI/CD or 'npm ci' runs). If you place a build-time or runtime package in devDependencies, your local build might work, but production or CI will break.
Always check if your package is referenced in nuxt.config.js, plugins, or modules: if so, it must be in dependencies.
macOS filesystems are case-insensitive by default, allowing 'import Home from "./components/home.vue"' even if the actual file is 'Home.vue'. CI servers (often Ubuntu-based) throw a 'Module not found' error.
Enforce consistent casing in file names and imports with tools like eslint-plugin-import or run your build on a case-sensitive FS locally for parity.
Monorepos add complexity: yarn/npm may hoist dependencies to the root, making them accessible locally but not in isolated installs (e.g., Docker, CI). Each workspace must declare its runtime dependencies, even if they're duplicated at the root.
Run `yarn workspaces info` to map dependency trees, and check that each package in your monorepo lists all build/runtime dependencies in its package.json.
Frequently asked questions
Can I leave Nuxt runtime dependencies in devDependencies?
No. Nuxt needs runtime dependencies declared in dependencies, not devDependencies, or production builds will fail.
Why does local build succeed but CI build fail?
Local node_modules may be stale or have hoisted/extra packages. CI installs from scratch, exposing missing or misplaced dependencies.
Is deleting node_modules enough to fix 'module not found' errors?
Often no. You must also remove the lockfile (package-lock.json or yarn.lock) before reinstalling to force a clean dependency tree.
Can I rely on hoisted dependencies in a monorepo?
No. Always list packages needed by a workspace in its own package.json, not just at the root.
Why does changing import casing matter?
macOS is case-insensitive; Linux and CI are not. Inconsistent import casing leads to 'module not found' errors outside your local dev machine.