The `nul` File Vite Generates on Windows and the Git Error It Causes

What Happened

I was building a Vite project using spec-driven development — feeding specs to AI and having it generate code. After building on Windows and trying to push with Git, I got an error:

error: invalid path 'dist/nul'

What? I checked, and sure enough — a file named nul had been generated inside the dist directory. And it appeared on every build. What is this thing?

Why This Happens

The culprit is Windows reserved device names.

For backward compatibility reasons, Windows has certain names reserved as device identifiers. The main ones:

• NUL — null device (equivalent to /dev/null on Linux)
• CON — console
• PRN — printer
• AUX — auxiliary device
• COM1–COM9 — serial ports
• LPT1–LPT9 — parallel ports

These names cannot be used as filenames even with an extension. nul.txt doesn’t work either. Case doesn’t matter.

Unix-based tools and libraries sometimes try to write to a /dev/null-style path, generating a path like nul on Windows. Vite or one of its dependencies appears to be doing exactly that.

Git can’t handle paths containing these reserved device names on Windows, which causes the push error.

The Fix

The fundamental fix would be a patch on the Vite side (or a dependency), but as a workaround, add it to .gitignore:

nul

That removes it from Git tracking and stops the error on push.

The AI-Driven Development Failure

For what it’s worth: when I let AI run in auto mode on this problem, it never solved it.

AI didn’t take the simple route of adding to .gitignore. Instead it kept looping through roundabout approaches — changing paths, adjusting character encodings — and went nowhere. I stopped it, manually deleted the nul file, added .gitignore myself, and it was fixed immediately.

If a human were writing the code from scratch, they’d probably catch and handle something like this right away. Even in an age where AI writes code, the ability to read source code and understand what’s happening still matters. This was a good reminder of that.

One More Thing

Windows development regularly surfaces these compatibility issues with Unix-first tools. When you see nul appearing somewhere, think “Windows reserved device name.”

While we’re at it, Japanese paths are another classic Windows development pitfall. If your project path contains Japanese characters — like C:\Users\Tanaka\projects\... — some build tools and libraries will throw mysterious errors. Use ASCII-only paths for projects.

Honestly, I keep wondering if the Japanese path problem will ever get fixed, but I doubt it. It’s not Vite’s fault specifically — it’s somewhere in the dependency chain (esbuild, rollup, etc.) where path handling breaks. Most OSS developers work on Mac or Linux, so Windows + Japanese paths rarely get tested. And since “put your project in an ASCII path” sidesteps the issue, there’s little motivation to fix it.

The “avoid Japanese paths” best practice is probably here to stay permanently. If your Windows username is in Japanese, just create a folder like C:\dev\ and keep your projects there.