`@slidev/conditional-styles` emits unresolvable Windows-path imports on pnpm (regression from #2573)
## Describe the bug
On Windows + pnpm, `pnpm dev` fails immediately with a `Failed to resolve import` from the `@slidev/conditional-styles` virtual module. The generated import URL is a nonsensical concatenation of the project root and the absolute file path:
```
Failed to resolve import "../Users/GUI.LECOMTE/source/repos/mpleo-demos/C:/Users/GUI.LECOMTE/source/repos/mpleo-demos/node_modules/.pnpm/@slidev+theme-default@0.25.0/node_modules/@slidev/theme-default/styles/index.ts" from "../../../../../@slidev/conditional-styles". Does the file exist?
Plugin: vite:import-analysis
File: /@slidev/conditional-styles:1:34
```
Reproduces with both `theme: default` and any third-party theme that ships `styles/index.{ts,js,css}`. Reproduces with the user project's own `style.ts` too — anything `templateConditionalStyles` tries to load.
## Suspected cause
This is a regression from #2573 (released in 52.15.1). That PR added a Windows-drive branch in `makeAbsoluteImportGlob`:
```js
const root = baseRoot && globs.some((glob) => RE_WINDOWS_DRIVE.test(slash(glob))) ? baseRoot : void 0;
// ...
...root ? { base: "/" } : {},
```
The resulting glob (`./node_modules/.pnpm/.../styles/index.{ts,js,css}` with `base: "/"`) appears to be valid by itself — the existing regression test in `test/utils.test.ts` only asserts the generated string. But when Vite expands the glob and emits per-match imports, it produces the broken `../Users/.../C:/Users/...` URL above, which `vite:import-analysis` then refuses.
The path-mangling looks like Vite computing a URL from the virtual module `/@slidev/conditional-styles` to the matched file, and on Windows with pnpm's deep `.pnpm/<pkg>@<peer-hash>/node_modules/<pkg>/` layout, the relative-URL math goes wrong.
#2567 (which #2573 fixed) and this issue together suggest the `makeAbsoluteImportGlob` helper needs an end-to-end test that actually loads `/@slidev/conditional-styles` through Vite — the string-only test can't catch this class of regression.
## Workaround
Patching `templateConditionalStyles.getContent` to bypass `makeAbsoluteImportGlob` and emit explicit `import "${toAtFS(candidate)}"` statements for each existing file resolves it:
```js
async getContent({ data, roots }) {
const imports = [];
for (const root of roots) {
for (const base of ["styles/index", "styles", "style"]) {
for (const ext of ["ts", "js", "css"]) {
const candidate = join(root, `${base}.${ext}`);
if (existsSync(candidate)) imports.push(`import "${toAtFS(candidate)}"`);
}
}
}
if (data.features.katex) imports.push(`import "${await resolveImportUrl("katex/dist/katex.min.css")}"`);
return imports.join("\n");
}
```
`templateGlobalLayers` and `createSetupTemplate` use the same helper and would need the same treatment if they ever match a real file under `.pnpm/` on Windows.
## Minimal reproduction
1. `pnpm create slidev` on Windows.
2. `pnpm dev`.
3. Observe the `Failed to resolve import` error above on first load.
## Environment
- Slidev: `52.15.2`
- Vite: `8.0.14`
- Node: `v25.9.0`
- OS: Windows 11
- Package manager: pnpm `10.33.0`
4 条评论