Dependency scan fails with incorrect file path when input contains @ in directory name on Windows

[zheung]

Describe the bug

When using a multi‑page configuration with input (not rolldownOptions.input), I always get a dependency scan error. The full error message is:

PS D:\desk\test-vite-scan\test> pnpm exec vite --force --host
dirPackage D:\desk\test-vite-scan\test
fileHTML   D:\desk\test-vite-scan\test\@src\whatever.html
14:19:27 [vite] (client) Forced re-optimization of dependencies

  VITE v8.2.2  ready in 195 ms

  ➜  Local:   http://localhost:5173/
  ➜  press h + enter to show help
(!) Failed to run dependency scan. Skipping dependency pre-bundling. Error: failed to resolve rolldownOptions.input value: "D:\\desk\\test-vite-scan\\test@src\\whatever.html".
    at resolvePath (file:///D:/desk/test-vite-scan/test/node_modules/.pnpm/vite@8.2.2/node_modules/vite/dist/node/chunks/node.js:31472:29)
    at async Promise.all (index 0)
    at async computeEntries (file:///D:/desk/test-vite-scan/test/node_modules/.pnpm/vite@8.2.2/node_modules/vite/dist/node/chunks/node.js:31477:41)
    at async scan (file:///D:/desk/test-vite-scan/test/node_modules/.pnpm/vite@8.2.2/node_modules/vite/dist/node/chunks/node.js:31420:19)
    at async file:///D:/desk/test-vite-scan/test/node_modules/.pnpm/vite@8.2.2/node_modules/vite/dist/node/chunks/node.js:34462:15

1. I do not set rolldownOptions.input anywhere in my config – I only set the standard input option.

2. The reported path is incorrect: it shows test@src (without a backslash between test and @src), but my actual directory structure is test\@src. The correct full path should be D:\desk\test-vite-scan\test\@src\whatever.html.

   I did further testing and found that any directory name that starts with @ at any level above the project root triggers this same error. For example, if my project is inside D:\some\@project\my-app, the error will show a malformed path missing the backslash before @project.

3. My OS is Windows 11. This issue cannot be reproduced on StackBlitz.

4. Even if my HTML file doesn't import any JavaScript files, this error still occurs.

vite.config.js

import { dirname, resolve } from 'path';
import { fileURLToPath } from 'url';

import { defineConfig } from 'vite';



const dirPackage = dirname(fileURLToPath(import.meta.url));
const fileHTML = resolve(dirPackage, '@src', 'whatever.html');

console.log('dirPackage', dirPackage);
console.log('fileHTML  ', fileHTML);

export default defineConfig(() => {
	return {
		input: {
			whatever: fileHTML,
		},
	};
});

screenshot

Reproduction

https://stackblitz.com/edit/vitejs-vite-kicw9xc5?file=vite.config.js

Steps to reproduce

No response

System Info

System:
    OS: Windows 11 10.0.26200
    CPU: (16) x64 AMD Ryzen 7 5800X 8-Core Processor             
    Memory: 37.64 GB / 63.92 GB
  Binaries:
    Node: 26.8.1 - e:\runtime\node\node.EXE
    npm: 11.19.0 - e:\runtime\node\npm.CMD
    pnpm: 12.0.0 - C:\Users\zheung\AppData\Roaming\npm\pnpm.CMD
  Browsers:
    Chrome: 151.0.7922.174
    Edge: Chromium (146.0.3856.62)
    Firefox: 145.0.2 - C:\Program Files\Mozilla Firefox\firefox.exe
  npmPackages:
    vite: ^8.2.2 => 8.2.2

Used Package Manager

pnpm

Logs

No response

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.

[bluwy]

Some context of how we handled this initially at #22642 (comment). I don't think the current PRs are solving this right, so I'm writing down some thoughts on the fix. Please don't use agents to get it done quickly.

Problem

We're currently reserving glob patterns for future use, but we still want to allow escaping so it works if you need to use paths that look like glob patterns. But of course in Windows this can be ambiguous:

• C:\root\@src\index.html
• .\@src\index.html
• ./path\@src\index.html (mixed slashes for some reason)

Possible ideas

A lot of this behaviour is based on tsdown's. From what I can tell, even if you use paths that look like glob, e.g. ./a*(z)/index.ts, and it uses tinyglobby to glob, it can still match the file as is. Like a file literally named ./a*(z)/index.ts.

So maybe the fix here is that if the path exists (resolved from root), then we don't need to check for glob patterns? In that case, we also likely don't need to unescape anymore? (Could be breaking if someone relied on it before though)

cc @sapphi-red

[sapphi-red]

It seems @ is only used for extglobs (which we don't support in many places due to the glob lib in rust not supporting it). Maybe we can make the unescape match more stricter to only match @( or decide that we never support extglobs. I'm in favor of dropping extglobs from everywhere.

[bluwy]

I don't think it's with extglobs only though. Paths like .\[foo]\index.html could also be incorrectly unescaped when the file exists as is.

If you don't unescape at all, and only check for globs for non-existing paths, I think this will only affect virtual inputs? Which means virtual inputs can't have glob patterns (or need escaping but we won't unescape for them).

These all also feel very complex that I wonder if it's worth anticipating glob support.

[sapphi-red]

Ah, that's true.

I think trying a normal resolution and then falling back to treat as globs makes sense. But I think it is better to try the resolveId resolution instead of a file check. The resolveId resolution in build seems to be needed in SSR bundled-dev so I'll probably tackle that together.

I think removing this unescaping for now is good.