Vite watcher crashing

Describe the bug

The following issue is happening on a large project I migrated from vue-cli to Vite. However, to eliminate as many variables as possible, I was able to reproduce the exact issue with a newly scaffolded project using the npm create vite@latest command.

The watcher process started by vite build --watch fails periodically. Issue #10096 is exactly what we are seeing happen. If I add a folder to my C:\ drive (or add files to any folder within the C:\ drive), the watcher fails. #10096 is closed and was supposedly fixed by #11261, but we are still seeing this happen, even with a newly scaffolded Vite project.

Using a watcher is integral to how my team works on our various Vue projects. While a fix is being investigated, are there any work arounds besides changing the directory of the project from the C:\ to D:\ drive? I can't remember what thread I found that workaround in, but this is not an acceptable workaround for my team.

Thanks in advance!

Reproduction

https://stackblitz.com/edit/vitejs-vite-ic568n?file=package.json,index.html&terminal=dev

Steps to reproduce

npm create vite@latest

Scaffolding options: Vue, TypeScript

vite build --watch

Add a new folder to your C:\ drive

System Info

System:
    OS: Windows 10 10.0.22621
    CPU: (24) x64 12th Gen Intel(R) Core(TM) i9-12900K
    Memory: 51.57 GB / 63.75 GB
Binaries:
    Node: 19.8.1 - C:\Program Files\nodejs\node.EXE
    npm: 9.5.1 - C:\Program Files\nodejs\npm.CMD
Browsers:
    Edge: Spartan (44.22621.1702.0), Chromium (113.0.1774.42)
    Internet Explorer: 11.0.22621.1
npmPackages:
    @vitejs/plugin-vue: ^4.2.3 => 4.2.3
    vite: 4.3.7 => 4.3.7

Used Package Manager

npm

Logs

(Parts of the file paths have been redacted)

node:events:498
Process terminated with code 1.
throw er; // Unhandled 'error' event
^
Error: EBUSY: resource busy or locked, lstat 'C:\DumpStack.log.tmp'
Emitted 'error' event on FSWatcher instance at:
at FSWatcher._handleError (file:///C:/Projects/clientapp/node_modules/rollup/dist/es/shared/watch.js:4251:10)
at ReaddirpStream.NodeFsHandler._boundHandleError (file:///C:/Projects/clientapp/node_modules/rollup/dist/es/shared/watch.js:2725:43)
at ReaddirpStream.emit (node:events:520:28)
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -4082,
code: 'EBUSY',
syscall: 'lstat',
path: 'C:\DumpStack.log.tmp'
}

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.

Start a new pull request in StackBlitz Codeflow.

vitejs-vite-ic568n (Open reproduction)

It seems this is because rollup watches /vite.svg.
https://stackblitz.com/edit/rollup-repro-zpgwkm?file=run.js,package.json

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

Lines 154 to 157 in 3f3fff2

    
           const publicFile = checkPublicFile(id, config) 
        
           if (publicFile) { 
        
             return id 
        
           }

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

Lines 181 to 182 in 3f3fff2

    
           const url = await fileToUrl(id, config, this) 
        
           return `export default ${JSON.stringify(url)}`

@sapphi-red removing the vite.svg image and references to it in a newly scaffolded Vite project fixes the issue.

This is obviously something we can't do in our actual projects (removing all images / static assets).

I'm assuming what you posted are the problem areas in Vite's code. Is there anything I can do with my own source code to mitigate the issue while a fix is worked on?

One of the methods I use is to trigger stably: when you use unocss, just create a file in the root directory of the disk where the project is located.

After removing '/__uno.css' from 'build watch', the project can be compiled normally without errors

like this:

defineConfig({
  build: {
		watch: {
			exclude: ['node_modules/**', "/__uno.css"]
		},
	}
})

This should be fixed in 5.0.0 as it's fixed in Rollup 4 (rollup/rollup#5013)

	const publicFile = checkPublicFile(id, config)
	if (publicFile) {
	return id
	}

	const url = await fileToUrl(id, config, this)
	return `export default ${JSON.stringify(url)}`