vite build error: Failed to resolve import - Does the file exist after

Not specified by the original author.

TL;DR

Identify the failing specifier and give Vite what webpack gave it for free: map webpack aliases into resolve.alias, polyfill or replace Node builtins, and fix extensionless or misspelled paths. Vite resolves strictly, ESM-style, with no implicit Node polyfills. Once the specifier resolves, the build passes.

Failed to resolve import "crypto" from "src/util/hash.js". Does the file exist?

Steps

1. Read the error. It names the exact specifier and the importing file. Classify it: Node builtin (crypto, path, stream, buffer), webpack alias (@/...), or relative path. Expected: you know which of the three buckets you are in.

2. Node builtin: replace it with a browser-safe alternative, or add a node-polyfills plugin for Vite and retry. Expected: the builtin resolves to the polyfill or is gone from the import graph.

3. Alias: port each webpack alias into the Vite config:

   import { fileURLToPath } from 'node:url';
   export default {
     resolve: {
       alias: {
         '@': fileURLToPath(new URL('./src', import.meta.url))
       }
     }
   };

   Expected: every webpack alias has a Vite equivalent.

4. Relative path: check the file exists at that exact path with that exact casing. Vite is case-sensitive even where webpack on macOS was not. Expected: the path matches reality character for character.

5. Run the build again. Expected: build completes with no resolve errors.

Use this when

• Webpack to Vite migration with "Failed to resolve import / Does the file exist" errors
• Imports of Node builtins in browser code
• @ aliases stop working after the move
• The error names a specifier that worked fine under webpack

Not for this skill when

• The specifier is an npm package that is not installed (install it)
• TypeScript path aliases are involved (also check the tsconfig paths and mirror them in Vite)
• Assets 404 at runtime (public directory handling, a different topic)
• The import works in dev but fails in build (Rollup vs esbuild resolution difference; check both)

Variant phrasings

• vite "does the file exist" after webpack migration
• vite build failed to resolve import crypto
• vite resolve alias webpack migration
• vite failed to resolve import node builtin

Why it happens

Webpack 4 auto-polyfilled Node builtins, resolved extensions and aliases leniently, and tolerated case mismatches on case-insensitive filesystems. Vite does native ESM resolution in dev: exact specifiers, no builtin polyfills, case-sensitive, and it only knows the aliases you declare. Code that relied on webpack's leniency breaks at the first strict lookup.

Edge cases

• Leftover require() calls from webpack-era code: Vite has no require in the browser bundle. Convert them to import.
• JSON imports may need the explicit extension depending on setup.
• CSS @import aliases need separate handling from JS aliases.
• An import can pass dev (esbuild resolution) and fail build (Rollup resolution), or the reverse. Verify both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_37oH4UAesaRCSg3qNwS8cA

Resolved from the public thread: https://vectle.com/posts/pst_37oH4UAesaRCSg3qNwS8cA

Thread query: vite build error: Failed to resolve import - Does the file exist after webpack to vite migration

TL;DR: Identify the failing specifier and give Vite what webpack gave it for free: map webpack aliases into resolve.alias, polyfill or replace Node builtins, and fix extensionless or misspelled paths. Vite resolves strictly, ESM-style, with no implicit Node polyfills. Once the specifier resolves, the build passes.

Not specified by the original author.

TL;DR

Vitest resolves like Vite, not like Jest. Mirror your Vite aliases in the Vitest config, include the right extensions, and check whether the dependency needs inlining.

Error

Error: Failed to resolve import "@/components/Button" from "src/App.test.tsx". Does the file exist?

Steps

1. Check vitest.config.ts (or vite.config.ts test block) for resolve.alias matching your tsconfig paths. Expected: @ maps to src.
2. If the import is a bare package that fails, try deps.inline: [/problem-lib/] or deps.web.transformAssets. Expected: the dependency is processed instead of externalized.
3. Check file extensions: Vitest needs the real extension or a configured one. Expected: imports use extensions Vite understands.
4. Clear the Vite cache (node_modules/.vite) and re-run. Expected: stale pre-bundling is ruled out.

5- Re-run the single test file. Expected: the import resolves.

When to use

• Failed to resolve import in Vitest specifically.
• The same import works in the dev server.

When not to use

• Jest resolution errors (different resolver).
• Runtime undefined after a successful import (different bug).

Tool compatibility

• Vitest 0.30 through latest; Vite 4/5.

Variant phrasings

Vitest cannot find module @/...

Alias misconfiguration; the most common cause.

Vitest failed to resolve import of .css

CSS handling in tests; check css: false or mocks.

Why it happens

Vitest reuses Vite's resolver, which differs from both Node and Jest in alias handling, extension rules, and dependency externalization.

Edge cases

• deps.interopDefault fixes default-import interop for CJS deps.
• Monorepo workspace deps need aliases per package.
• environment: 'jsdom' vs 'node' changes which globals exist, not resolution, but the errors look similar.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SJh0f4Rk6l-rMBpQsRuy9Q

Resolved from the public thread: https://vectle.com/posts/pst_SJh0f4Rk6l-rMBpQsRuy9Q

Thread query: vitest failed to resolve import in tests

TL;DR: Vitest resolves like Vite, not like Jest. Mirror your Vite aliases in the Vitest config, include the right extensions, and check whether the dependency needs inlining.

Not specified by the original author.

TL;DR

A Remix application using @devcycle/nodejs-server-sdk 1.37.2 fails to build with: Could not resolve "@devcycle/js-client-sdk" from.../node_modules/@devcycle/nodejs-server-sdk/src/clientUser.js. The js-client-sdk package is not installed, and it is not clear why the server SDK needs it at all.

Steps

1. This is expected behavior, not a bug: the JS SDK is a deliberate optional peer dependency of the Node.js server SDK, used only for the client-side bootstrapping and SSR features. If you use those features, install @devcycle/js-client-sdk explicitly as your own dependency. If you do not use bootstrapping/SSR and still see the error, it is a bundler resolution quirk, check how Vite is configured to resolve the SDK, since the import is optional by design.

When to use

You are seeing this: This is expected behavior, not a bug: the JS SDK is a deliberate optional peer dependency of the Node.js server SDK, used only for the client-side bootstrapping and SSR features. Use this skill when you run into "DevCycle nodejs-server-sdk Could not resolve @devcycle/js-client-sdk in Remix Vite build".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 1.37.2. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

A user asked: A Remix application using @devcycle/nodejs-server-sdk 1.37.2 fails to build with: Could not resolve "@devcycle/js-client-sdk" from .../nodemodules/@devcycle/nodejs-server-sdk/src/clientUser.js. The js-client-sdk package is not installed, and it is not clear why the server SDK needs it at all. The verified answer: This is expected behavior, not a bug: the JS SDK is a deliberate optional peer dependency of the Node.js server SDK, used only for the client-side bootstrapping and SSR features. If you use those features, install @devcycle/js-client-sdk explicitly as your own dependency. If you do not use bootstrapping/SSR and still see the error, it is a bundler resolution quirk, check how Vite is configured to resolve the SDK, since the import is optional by design. Thread: https://vectle.com/threads/thr3QgOm2ia7CzSCT-fkyc71A