Issue with 404 typescript files

[CRodz13]

Not sure why browser is trying and failing to find these files. if i load/reload page it attempts to find all of them. Doesnt appear to happen in production, just in dev mode. tried reinstalling, updating to latest and clearing cach, node modules etc. Any ideas? This is not a typescript app. its js

[gpbl]

Hi @CRodz13 could you help us to reproduce your problem in a CodeSandbox? Thanks!

[luckeymz7]

i am having the same problem:

I am using next js v15, and shadcn/originui components

Some of my components
date ranger picker: https://pastebin.com/Kbt4C7U7
Calendar: https://pastebin.com/iCssqihU

"date-fns": "^4.1.0",     
"react-day-picker": "^9.7.0",

[jeanfrancois-handfield]

I had the same issue and the security guys fixed it. There was a problem with the proxy and deepinspect

[mmle10]

i had the same problem and tried running without turbopack and the 404 erros disappeared

[Andrew-Forster]

I can also confirm, having the same issue.

Running the server with webpack will fix it so it seems to be something with the interaction between it and turbopack. Really sucks cause turbopack provides such awesome UI/

[Andrew-Forster]

Solved this issue!:

It's a weird combination of React day picker, turbopack and dev-tools. For some reason, together they trigger this issue.

Fixed it by disabling the "Enable JavaScript source maps" checkbox in dev-tool settings.

[Andrew-Forster]

1. Source Maps Only Loaded When DevTools Are Active

By default, Chrome (and other browsers) only fetch JavaScript source map files when DevTools is opened. If DevTools is closed, no map files are requested at all—even if //# sourceMappingURL comments exist in your bundles. That’s why you only saw requests like GET /src/components/Weekdays.tsx 404 while DevTools was open.
Source: Chrome DevTools documentation and community reports confirm this behavior.GitHub+13Chrome for Developers+13Atlassian Support+13

2. Source Maps Point to .tsx in Third‑Party Libraries

Tools like React DayPicker include source map metadata referencing their internal TypeScript source files (e.g. .tsx paths under /src/…). When Turbopack bundles the library, it retains these references. Thus, DevTools attempts to fetch maps for these .tsx files. Since those files aren't actually served by the dev server, the requests result in 404 errors—only visible in DevTools.Chrome for DevelopersAtlassian SupportDjango Forum

3. Turbopack Serves Modules Individually in Dev Mode

Unlike Webpack, Turbopack serves ESM modules individually to optimize refresh performance. This means when DevTools requests a .tsx map path Turbopack attempts to resolve it—even though the file doesn’t exist—leading to a 404. The behavior is typical when handling unbundled ESM modules with embedded source maps.GitHub+1New Releases+1

---

🧪 Summary: Why This Was Happening

Behavior | Explanation -- | -- 404 messages appear only when DevTools is open | DevTools triggers source map requests (.tsx files) only when active Requests referencing /src/...tsx | DayPicker’s build includes source map links to TypeScript source paths Turbopack dev server logs these GETs | It tries to serve each file path individually, but they don't exist

1. Source Maps Only Loaded When DevTools Are Active By default, Chrome (and other browsers) only fetch JavaScript source map files when DevTools is opened. If DevTools is closed, no map files are requested at all—even if //# sourceMappingURL comments exist in your bundles. That’s why you only saw requests like GET /src/components/Weekdays.tsx 404 while DevTools was open. Source: Chrome DevTools documentation and community reports confirm this behavior. GitHub +13 Chrome for Developers +13 Atlassian Support +13

2. Source Maps Point to .tsx in Third‑Party Libraries
   Tools like React DayPicker include source map metadata referencing their internal TypeScript source files (e.g. .tsx paths under /src/…). When Turbopack bundles the library, it retains these references. Thus, DevTools attempts to fetch maps for these .tsx files. Since those files aren't actually served by the dev server, the requests result in 404 errors—only visible in DevTools.
   Chrome for Developers
   Atlassian Support
   Django Forum

3. Turbopack Serves Modules Individually in Dev Mode
   Unlike Webpack, Turbopack serves ESM modules individually to optimize refresh performance. This means when DevTools requests a .tsx map path Turbopack attempts to resolve it—even though the file doesn’t exist—leading to a 404. The behavior is typical when handling unbundled ESM modules with embedded source maps.
   GitHub
   +1
   New Releases
   +1

🧪 Summary: Why This Was Happening
Behavior Explanation
404 messages appear only when DevTools is open DevTools triggers source map requests (.tsx files) only when active
Requests referencing /src/...tsx DayPicker’s build includes source map links to TypeScript source paths
Turbopack dev server logs these GETs It tries to serve each file path individually, but they don't exist

[jeanfrancois-handfield]

This fixed the issue

[gpbl]

Thanks of the reports here, this should be fixed with #2812 (published in v9.9.0).