Could not resolve "../styles/Randomfacts.css" from "src/pages/Randomfacts.tsx"
Error: Command "npm run build" exited with 1
This was my first deploy to Vercel, and my first thought was that I'd broken something in that commit.
I opened Randomfacts.tsx and found it importing Randomfacts.css — capital R. Then I checked the actual file sitting in src/styles/, and its name was randomfacts.css, lowercase.
So the import was wrong. Fine. But that raised a much more confusing question:
Why had npm run build never thrown this error on my machine?
The actual cause
Windows filesystems are case-insensitive. Ask for Randomfacts.css when the file is called randomfacts.css and Windows hands it over without comment. Both spellings resolve to the same file, so the mismatched import worked locally for months.
Vercel builds on Linux, which compares filenames byte for byte. There, R and r are genuinely different names — and the one my import asked for didn't exist.
Same code, same import, two different answers. The operating system answered, not the bundler.
The fix
I matched the import to the real filename. Then a Windows wrinkle worth knowing: a case-only rename won't be recorded by git, so if you rename the file instead of the import, it takes two steps.
git mv src/styles/randomfacts.css src/styles/temp.css
git mv src/styles/temp.css src/styles/Randomfacts.css
How to catch these before the build does
Use git ls-files rather than ls. It shows the name git actually recorded, which is what the build server checks out — your local filesystem will happily lie to you here.
git ls-files src/styles/
Compare that output against your imports. Any casing mismatch is a build failure waiting for your next deploy.
What I took from it
There's a whole class of bugs that only exist when your deploy environment differs from your development one. Case sensitivity is the most common. Path separators and missing environment variables are close behind. None of them are visible while you're only running things locally, and none have anything to do with your logic being wrong.
I'd been building this project on and off for months — adding functionality in bursts, brushing up on different concepts along the way — and only hit this on the first deploy. It would have taken ten seconds to spot if I'd deployed at the start.
That's the real lesson for me. Deploy early, even when the project isn't finished. Not for the URL, but because the deploy environment finds a category of bug that your machine structurally cannot.
