Describe the bug

Hi, we're seeing a dev-mode issue with @vanilla-extract/vite-plugin when a workspace *.css.ts module is resolved through a Vite id shaped like @id/C:/....

We first observed this naturally on Windows in a pnpm monorepo. We then built a minimal repro and found that the same underlying failure can also be triggered on macOS/Linux by simulating that same Vite id shape. So this no longer looks Windows-only; Windows just seems to be where that id form shows up naturally in real projects.

Versions:

• @vanilla-extract/vite-plugin: 5.2.1
• @vanilla-extract/compiler: 0.6.0
• vite: reproduced in minimal repro with 6.3.3, originally observed in a real app with 8.0.8
• node: reproduced locally with Node 20.17.8; originally observed with Node 24.14.1

Context:

• pnpm monorepo
• Vite app imports *.css.ts from a sibling workspace package
• happens in dev mode
• production build works

What happens:
@vanilla-extract/vite-plugin eventually calls getCssForFile(...) with a file path that does not match the compiler cache key and throws:

Error: No CSS for file: .../@id/C:/.../block.css.ts
    at Object.getCssForFile (...@vanilla-extract/compiler...)
    at ResolveIdContext.resolveId (...@vanilla-extract/vite-plugin...)

Example stack:

at Object.getCssForFile (.../node_modules/@vanilla-extract/compiler/dist/vanilla-extract-compiler.cjs.dev.js:415:15)
at ResolveIdContext.resolveId (.../node_modules/@vanilla-extract/vite-plugin/dist/vanilla-extract-vite-plugin.cjs.dev.js:256:81)
at EnvironmentPluginContainer.resolveId (.../node_modules/vite/dist/node/...)
at async EnvironmentModuleGraph._resolveUrl (...)
at async EnvironmentModuleGraph.getModuleByUrl (...)

Why we think @id/C:/... is the key part:

• In the real app, the failure appeared when Vite/TanStack-style dev resolution produced ids shaped like @id/C:/...
• In the minimal repro, we can trigger the same failure on macOS by simulating:

/@id/C:/.../block.css.ts.vanilla.css

Expected:
@vanilla-extract/vite-plugin should normalize or otherwise handle Vite ids shaped like @id/C:/... consistently in dev mode, so they map to the same compiler cache entry as the original *.css.ts file.

Actual:
The plugin looks up CSS using a mismatched path and throws No CSS for file.

Current workaround:
We can work around this by adding a small Vite resolveId normalization step before vanilla-extract sees the id, rewriting values shaped like:

@id/C:/foo/bar.css.ts

back to:

C:/foo/bar.css.ts

That avoids the mismatch.

See the minimal reproduction repo as well.

Reproduction

https://github.com/MagneH/vanilla-extract-vite-windows-bug-repro

System Info

System info:
- Reproduced locally on macOS 26.3.1 (build 25D2128), arm64
- Node.js: 24.14.0
- pnpm: 10.33.0
- vite: 6.3.3 (minimal repro)
- @vanilla-extract/vite-plugin: 5.2.1
- @vanilla-extract/compiler: 0.6.0

Also originally observed in a real app on:
- Windows
- Node.js: 24.14.1
- vite: 8.0.8

Used Package Manager

pnpm

Logs

at Object.getCssForFile (.../node_modules/@vanilla-extract/compiler/dist/vanilla-extract-compiler.cjs.dev.js:415:15)
at ResolveIdContext.resolveId (.../node_modules/@vanilla-extract/vite-plugin/dist/vanilla-extract-vite-plugin.cjs.dev.js:256:81)
at EnvironmentPluginContainer.resolveId (.../node_modules/vite/dist/node/...)
at async EnvironmentModuleGraph._resolveUrl (...)
at async EnvironmentModuleGraph.getModuleByUrl (...)

Validations

• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• The provided reproduction is a minimal reproducible example of the bug.