vite: Failed to load vite.config.js during build - Cannot use import statement outside a module

Describe the bug

I’m trying to npm run build with the latest Vite 4.3 having a package.json without “type”: “module” specified in it and I get the following error:

failed to load config from .../vite.config.js
error during build:
import { defineConfig } from 'vite'
^^^^^^

SyntaxError: Cannot use import statement outside a module

I’m using the default vite.config.js created via npm create vue@latest and the import/export statements in it should be pre-processed according to the documentation https://vitejs.dev/config/ but it seems to be failing. Note Vite supports using ES modules syntax in the config file even if the project is not using native Node ESM, e.g. type: "module" in package.json. In this case, the config file is auto pre-processed before load.

Reverting to vite@4.2.2 fixes the issue.

Reproduction

https://vitejs.dev/config/

Steps to reproduce

npm create vue@latest npm install npm run build

System Info

node 16.20
npm 8.19.4
vite 4.3

Used Package Manager

npm

Logs

No response

Validations

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 1
  • Comments: 29 (5 by maintainers)

Commits related to this issue

Most upvoted comments

@nickturrietta In my case it was not a mapped drive in question. I have local, regular drives in my Windows machine.

However, I’ve found a simple solution: renamed vite.config.js to vite.config.mjs and npm run build now runs just fine - tested on both vite 4.3.0 and 4.3.1. Using the mjs config file also works with 4.2.2.

Here is the full error stack I’m seeing:

failed to load config from c:\Users\fwouts\dev\hungry\vite.config.ts
500 in endpoint /previews/start:
c:\Users\fwouts\dev\hungry\vite.config.ts:1
import { defineConfig } from "vite";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at internalCompileFunction (node:internal/vm:73:18)
    at wrapSafe (node:internal/modules/cjs/loader:1176:20)
    at Module._compile (node:internal/modules/cjs/loader:1218:27)
    at Module._extensions..js (node:internal/modules/cjs/loader:1308:10)
    at _require.extensions.<computed> [as .js] (file:///C:/Users/fwouts/.vscode/extensions/zenclabs.previewjs-1.22.0/dist/node_modules/.pnpm/vite@4.3.1/node_modules/vite/dist/node/chunks/dep-24daf00c.js:64459:17)
    at Module.load (node:internal/modules/cjs/loader:1117:32)
    at Module._load (node:internal/modules/cjs/loader:958:12)
    at Module.require (node:internal/modules/cjs/loader:1141:19)
    at require (node:internal/modules/cjs/helpers:110:18)
    at loadConfigFromBundledFile (file:///C:/Users/fwouts/.vscode/extensions/zenclabs.previewjs-1.22.0/dist/node_modules/.pnpm/vite@4.3.1/node_modules/vite/dist/node/chunks/dep-24daf00c.js:64464:21)

This is with a package.json that doesn’t have "type": "module", and I have checked that isESM is false here. The config file is correctly transpiled to CJS here but the following line fails, perhaps because of the equality check here? I’ll try to debug this a bit further later today.

Update: confirmed, both sides of the equality check have a different casing:

"c:\Users\fwouts\dev\hungry\vite.config.ts" vs "C:\Users\fwouts\dev\hungry\vite.config.ts"

@xsjcTony No, your case didn’t reproduce on my computer.

Thanks for testing @sapphi-red but never mind since it has been resolved in the latest release.

Update: confirmed, both sides of the equality check have a different casing:

"c:\Users\fwouts\dev\hungry\vite.config.ts" vs "C:\Users\fwouts\dev\hungry\vite.config.ts"

@fwouts Great find! I think renaming vite.config.js to vite.config.mjs solves the issue (in my case) because loading an mjs file takes a different resolve path in vite, bypassing the code that generates the bug https://github.com/vitejs/vite/pull/12553#discussion_r1175933969

cc: @patak-dev @bluwy Please take a look at this, now that the bug has been found.

I’m also seeing this issue with https://github.com/fwouts/previewjs although it’s not happening in CI.

I wonder if it’s to do with the file system being configured to be case sensitive or not?

I tried a few different Vite versions, here are the results:

  • 4.3.1 = broken
  • 4.3.0 = broken
  • 4.3.0-beta.4 = broken
  • 4.3.0-beta.2 = broken
  • 4.3.0-beta.1 = broken
  • 4.3.0-beta.0 = working
  • 4.2.1 = working

Given this, I assume the culprit is in https://github.com/vitejs/vite/compare/v4.3.0-beta.0...v4.3.0-beta.1. Perhaps https://github.com/vitejs/vite/pull/12580?

Edit: I tried reverting https://github.com/vitejs/vite/pull/12580 locally on top of 4.3.1 and I don’t think it resolves it.

Just rename to vite.config.mjs #12923 (comment) and everything works perfectly fine with latest vite 4.3.1.

Doesn’t help in my case, just throws another error:

failed to load config from c:\...\vite.config.mjs
error during build:
TypeError: laravel is not a function

It happend to me too.

I thought it was related to my latest upgrade of nodejs to v20.0.0, but it still occurred when I reverted back to v18.16.0.

What I did after the node update, I deleted my node_modules folder and ran “node update” to reinstall the packages.

I found that I was originally on vite v4.2.2 and it updated to v4.3.1 since my package.json was looking for “vite”: “^4.0.0”.

I took vite back to v4.3.0 and still had the issue. So I went back to v4.2.2 since I did not want to walk thru all the 4.3 beta versions. And I also went back to v20.0.0 of node.

All are working so far.

Environment:

Laravel Version - v10.8.0 Laravel Vite plugin v0.7.4 PHP Version - v8.2.0 Composer Version - v2.5.5 OS - Windows 11 Home, Version 22H2 npm - v9.6.5 node - v20.0.0 vite - v4.3.1 (now v4.2.2)

I ran into this same error today as well.

Did more Github searching and stumbled on this https://github.com/vitejs/vite/issues/4833#issuecomment-912592076

So, in my particular case, this is related to the fact that I was executing npm run build on a mapped drive in Windows.

My quick fix was to navigate to the target directory and run npm run build there, instead of the mapped drive.

This is obviously less than ideal however, and this should still be considered a regression.