Regression in 4.3 with Linaria in dev mode

[nstepien]

Describe the bug

When running vite, I now get this error:

  VITE v4.3.1  ready in 476 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
Failed to load url /main_1nkbhq3.css (resolved id: D:/repos/vite-bug/main_1nkbhq3.css) in D:/repos/vite-bug/main.js. Does the file exist?

It works fine with vite build + vite preview.
vite@~4.2.0 works fine too in either dev or prod builds.
Not sure if this is an issue with linaria or with vite, I've opened an issue in the linaria repo as well.

Reproduction

https://github.com/nstepien/vite-bug/tree/vite43

Steps to reproduce

Clone the repo, checkout the vite43 branch, npm ci
npm run dev -> white page 🛑 it should be green
npm run build + npm run preview -> green page ✅

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (64) x64 AMD Ryzen Threadripper 3970X 32-Core Processor 
    Memory: 20.61 GB / 31.88 GB
  Binaries:
    Node: 20.0.0 - C:\Program Files\nodejs\node.EXE
    npm: 9.6.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Spartan (44.22621.1555.0), Chromium (112.0.1722.48)
    Internet Explorer: 11.0.22621.1
  npmPackages:
    vite: ^4.3.1 => 4.3.1

Used Package Manager

npm

Logs

  VITE v4.3.1  ready in 495 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h to show help
  vite:html-fallback Rewriting GET / to /index.html +0ms
  vite:resolve 2.39ms /main.js -> D:/repos/vite-bug/main.js +0ms
  vite:time 22.23ms /index.html +0ms
  vite:load 1.79ms [fs] /main.js +0ms
  vite:import-analysis 3.04ms [1 imports rewritten] main.js +0ms
  vite:transform 145.38ms /main.js +0ms
  vite:resolve 0.24ms /@vite/client -> D:/repos/vite-bug/node_modules/vite/dist/client/client.mjs +151ms
Failed to load url /main_1nkbhq3.css (resolved id: D:/repos/vite-bug/main_1nkbhq3.css) in D:/repos/vite-bug/main.js. Does the file exist?
  vite:cache [304] /main.js +0ms
  vite:time 0.41ms /main.js +153ms
  vite:load 2.05ms [fs] /@vite/client +150ms
  vite:resolve 0.11ms @vite/env -> D:/repos/vite-bug/node_modules/vite/dist/client/env.mjs +18ms
  vite:import-analysis 2.35ms [1 imports rewritten] node_modules\vite\dist\client\client.mjs +20ms
  vite:transform 14.55ms /@vite/client +19ms
  vite:time 19.22ms /@vite/client +17ms
  vite:html-fallback Not rewriting GET /main_1nkbhq3.css because the path includes a dot (.) character. +192ms
  vite:time 1.12ms /main_1nkbhq3.css +2ms
  vite:load 3.18ms [fs] /node_modules/vite/dist/client/env.mjs +19ms
  vite:import-analysis 0.08ms [no imports] node_modules\vite\dist\client\env.mjs +4ms
  vite:transform 0.59ms /node_modules/vite/dist/client/env.mjs +4ms
  vite:cache [304] /node_modules/vite/dist/client/env.mjs +22ms
  vite:time 0.27ms /node_modules/vite/dist/client/env.mjs +3ms

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

This seems to be affected by #12655.

1. linaria plugin injects a import like import "C:\project\main_hash.css".
2. this.resolve in plugin import-analysis gets called.
3. linaria plugin resolves C:\project\main_hash.css as-is.
4. But the plugin container normalizePath that result to C:/project/main_hash.css.
5. linaria plugin fails to return the content with load hook because C:\project\main_hash.css exists but C:/project/main_hash.css doesn't exist.

resolved variable here is the result of this.resolve(url, importFile).

vite/packages/vite/src/node/plugins/importAnalysis.ts

Line 314 in e7924d2

const resolved = await this.resolve(url, importerFile)

But later on there's a url = resolved.id.

vite/packages/vite/src/node/plugins/importAnalysis.ts

Lines 347 to 349 in e7924d2

	} else {
	url = resolved.id
	}

So the this.resolveId inside moduleGraph.ensureEntryFromUrl was doing something like this.resolve(resolved.id).
#12655 changed that to this.resolve(url) as it skips the this.resolve.

[sorenhoyer]

I have the same problem. Reverting to 4.2 for now.

[patak-dev]

I think that this may not be a regression, and it is better to be fixed in the Linaria plugin. We discussed potential issues related to meta with @bluwy in the discussion of the linked PR. And our conclusion was that it is required for the plugin to return the same meta while resolving the file during import analysis and when resolving the already-resolved-and-browser-friendly-url as requested later by the browser. And the same goes for the returned id. Both should end up resolving to the same id. So I think normalizePath is needed in the Linaria plugin. @nstepien I see you already fixed this issue for Linaria:

• Normalize import path in the Vite plugin to fix Vite builds on Windows callstack/linaria#1201

Let's close this one for now and let us know if you see anything else odd with Vite 4.3.

@sorenhoyer please create a new issue with a minimal reproduction if your issue isn't related to Linaria. Or if you have the same kind of problem, check if you are missing a normalize path.
Also related https://vitejs.dev/guide/api-plugin.html#path-normalization