Expected identifier but found "import" (define name) in Vite

TL;DR#

Vite loads vite.config.js by bundling it with esbuild. While doing that, Vite 6 passes esbuild a define block whose keys include import.meta.url, import.meta.dirname and import.meta.filename. esbuild 0.24.1 introduced a regression that rejects define keys starting with import, so each of those three keys fails with Expected identifier but found "import". Vite cannot load its config, and both vite and vite build stop. Vite 6.0.0 to 6.0.4 accept any esbuild in the ^0.24.0 range, so they can end up with 0.24.1. Once a lockfile records that version, npm install and npm ci keep restoring it. Run npm update esbuild to move to the fixed esbuild, then upgrade to the newest Vite 6 release, which depends on a newer esbuild line.

The question is the Stack Overflow question "Errors while starting vite + react": a frontend folder created with Vite, inside a full-stack project, which prints three errors on npm run dev and never starts. The failure, the negative controls and every fix below were reproduced on 20 October 2026 in the official node:22.12.0-alpine Docker image (npm 10.9.0). The test project was the smallest one that loads a config: an index.html, a main.js and a vite.config.js that only exports defineConfig({}). React is not involved. The error happens before any plugin runs, so a React template fails in exactly the same way.

The error, reproduced#

With Vite 6.0.4 and esbuild 0.24.1 installed, npm run dev prints the same output as the question, apart from the project path:

> frontend@0.0.0 dev
> vite
 
✘ [ERROR] Expected identifier but found "import"
 
    (define name):1:0:
      1 │ import.meta.dirname
        ╵ ~~~~~~
 
✘ [ERROR] Expected identifier but found "import"
 
    (define name):1:0:
      1 │ import.meta.filename
        ╵ ~~~~~~
 
✘ [ERROR] Expected identifier but found "import"
 
    (define name):1:0:
      1 │ import.meta.url
        ╵ ~~~~~~
 
failed to load config from /work/broken/vite.config.js
error when starting dev server:
Error: Build failed with 3 errors:
(define name):1:0: ERROR: Expected identifier but found "import"
(define name):1:0: ERROR: Expected identifier but found "import"
(define name):1:0: ERROR: Expected identifier but found "import"
    at failureErrorWithLog (/work/broken/node_modules/esbuild/lib/main.js:1476:15)

npm run build fails the same way. The only difference is that the last line before the stack reads error during build: instead of error when starting dev server:. The useful part is (define name):1:0. The error does not point at a line in your code. It points at the name of a define entry, and vite.config.js above defines nothing.

Why esbuild rejects Vite's define keys#

To load a config file, Vite bundles it with esbuild first and then imports the result. In the Vite 6.0.4 source, the bundleConfigFile function in packages/vite/src/node/config.ts calls esbuild's build with this define block (other options left out), so that a config file can use __dirname and import.meta.url and still get the path of the config file:

const result = await build({
  // ...other options
  define: {
    __dirname: dirnameVarName,
    __filename: filenameVarName,
    'import.meta.url': importMetaUrlVarName,
    'import.meta.dirname': dirnameVarName,
    'import.meta.filename': filenameVarName,
  },
})

esbuild 0.24.1 changed how it parses define names, so that names can contain quoted property names. The esbuild changelog for 2024 describes the side effect in the entry for 0.24.2:

The previous change in version 0.24.1 to use a more expression-like parser for define values to allow quoted property names introduced a regression that removed the ability to use --define:import.meta=.... Even though import is normally a keyword that can't be used as an identifier, ES modules special-case the import.meta expression to behave like an identifier anyway. This change fixes the regression.

This matches the output exactly. Five keys go in, and the three that start with import.meta come back as errors, while __dirname and __filename pass. The same failure was reported against esbuild in issue #4010 (Windows 10, Node v22.12.0, a new Vite project) and against Vite in issue #19018.

Why a project from the same template can work on another machine#

Whether you get the error depends on which esbuild the lockfile records, not on your code. The npm registry entry for Vite shows the dependency range of each release:

The same registry data for esbuild dates the window. esbuild 0.24.1 was published on 20 December 2024 at 05:42 UTC, and 0.24.2 the same day at 17:57 UTC. Vite 6.0.5 was published at 11:37 UTC that day, with the changelog line "fix: esbuild regression (pin to 0.24.0) (#19027)". Any install that resolved esbuild afresh for Vite 6.0.0 to 6.0.4 while 0.24.1 was the newest esbuild wrote "version": "0.24.1" into package-lock.json. That project fails today on every machine that installs from the lockfile. A fresh install of Vite 6.0.4 today gets 0.24.2 and works, which is why the same template can fail for one developer and work for another.

Fix#

1. Confirm which esbuild Vite is using#

npm ls esbuild

On the failing project:

`-- vite@6.0.4
  `-- esbuild@0.24.1

If the version under vite is 0.24.1, you have this error. If it is something else, the cause is somewhere else and the rest of this page does not apply.

2. Update esbuild in the lockfile#

npm update esbuild

This keeps your Vite version. npm resolves esbuild again inside the range Vite 6.0.4 allows, finds the newest 0.24 release and writes it to package-lock.json. In the test project it reported changed 2 packages in 1s, and then:

`-- vite@6.0.4
  `-- esbuild@0.24.2

Commit the updated package-lock.json. If you do not, the next npm ci on CI or on a teammate's machine restores 0.24.1.

3. Then move to the newest Vite 6 release#

npm install -D vite@6

Step 2 is the smallest change that unblocks the project, but it leaves you on esbuild 0.24.2 and Vite 6.0.4. The GitHub advisory GHSA-67mh-4wv8-2f99 lists esbuild up to 0.24.2 as affected, with 0.25.0 as the first patched version. Vite 6.0.5 was the release that first avoided this error, by pinning esbuild to 0.24.0, but on 20 October 2026 the GitHub advisory database, queried through its API for advisories affecting vite@6.0.5, returned sixteen advisories affecting Vite 6.0.5 or its editor-launching dependency, seven of them bypasses of the dev server's server.fs.deny file protection. The same query for vite@6.4.4 returned none. Vite 6.0.5 is therefore not the version to stop at.

Run on the failing project, the command above installed Vite 6.4.4, the newest 6.x release on 20 October 2026, which depends on ^0.25.0. npm ls esbuild then showed esbuild@0.25.12 under vite@6.4.4, and the build passed. Staying on Vite 6 avoids the changes of a new major. Moving to a later major is a separate upgrade, with its own migration notes.

Verify the fix#

Run the build, or start the dev server, from the same folder:

npm run build

After npm update esbuild, the same project builds:

vite v6.0.4 building for production...
✓ built in 126ms

The reproduction checked the fix with npm run build. The dev server fails at the same failed to load config step, so start it too: it should now print its local URL. If the output still shows (define name):1:0, run npm ls esbuild again: a second copy of esbuild nested under another package can still be on 0.24.1.

What reinstalling, pinning and downgrading actually do#

The usual first move is to wipe node_modules. With the lockfile still in place, that changes nothing. In the reproduction, the lockfile contained:

    "node_modules/esbuild": {
      "version": "0.24.1",

Both rm -rf node_modules && npm install and npm ci installed 11 packages and resolved esbuild@0.24.1 under vite@6.0.4 again, and the build failed with the same three errors. The lockfile is the record of the bad version. Reinstalling only replays it.

The two highest-voted answers on the question also work, for reasons the reproduction makes visible:

• npm i -D esbuild@0.24.0 (the first answer) adds esbuild as a direct dependency of your project. Because 0.24.0 also satisfies Vite's ^0.24.0, npm uses one copy for both, and npm ls esbuild shows esbuild@0.24.0 deduped under Vite. The build passes. The cost is a direct dependency your code never imports, pinned to an old release, which you will have to remember to remove. npm update esbuild does the same job without adding it.
• npm install vite@^5 (the second answer) works because Vite 5.4.11 depends on ^0.21.3, a different esbuild line. This one was not reproduced here: the registry entry is the evidence. It gives up Vite 6 to avoid a bug that a patch release of Vite 6 already avoids.

The third answer, Vite 6.0.5, was reproduced: with no override, it resolved esbuild@0.24.0 and built. It works for this error, and step 3 explains why the newest Vite 6 release is the better target.

Two controls isolate the cause. Vite 6.0.4 with esbuild forced to 0.24.0 builds, and Vite 6.0.4 with esbuild forced to 0.24.2 builds. Only 0.24.1 fails. With Vite held at 6.0.4, only the esbuild version changes the outcome; the config file and the project layout play no part, and having a separate backend folder next to frontend, as in the question, is not the cause.

Not the Docker "esbuild-linux-64" error#

Two esbuild failures can stop vite before it starts. They have different causes and different fixes. If your error says The package "esbuild-linux-64" could not be found, or that you installed esbuild for another platform, esbuild never ran: the binary for your platform is missing, usually because a bind mount brought a macOS or Windows node_modules into a Linux container. That case is covered in the page on the esbuild platform error with Vite in Docker. The error on this page is the opposite situation. The stack goes through handleIncomingPacket and Socket.readFromStdout, which means the esbuild binary started, read Vite's request and answered with parse errors. The reproduction ran in a plain Linux container, with no project folder or node_modules mounted from the host: everything was installed inside the container. Changing nothing but the esbuild version from 0.24.1 to 0.24.2 made the error disappear.

The same trap, where reinstalling only replays the old version of a dependency recorded in the lockfile, appears in the Windows DLL load error with Rollup, where the root cause is a missing Visual C++ runtime and npm update rollup is one of the fixes. A different define failure, in Vite 2, is covered in the Vite build "Unexpected token" error caused by define: there the problem is the values you put in your own define block, which Vite 2 pastes into the code as text at build time. And if npm run build now stops on a top-level await while npm run dev works, see the Vite "Top-level await is not available" build error.

Before deleting files or downgrading, read the version under vite in npm ls esbuild. If it says 0.24.1, run one update and commit the lockfile. The error came from an esbuild release that was the newest one for about twelve hours, and that release stays in your project only as long as the lockfile records it.

Further reading: Chrome hangs with Vite dev server: raise the file limit.