mime type change critical crash

[Bader-Idris]

🐛 The bug

I've flipping my app for an entire week searching for the reason, thanks to firefox browser it showed up, I use google analytics and google tag manager in my nuxt 4.4.4 app with nuxt script 1.0.6, this is my scripts object in nuxt config file:

scripts: {
 registry: {
googleAnalytics: {
 id: process.env.GOOGLE_ANALYTICS_MEASUREMENT_ID,
 trigger: 'onNuxtReady'
 },
googleTagManager: {
 id: process.env.GOOGLE_TAG_MANAGER_ID,
 trigger: 'onNuxtReady'
 }, },
 },

// after updating them from boolean value

the browser in dev says:

The script from “http://localhost:3000/_scripts/assets/298b21fc6f49a22c.js?id=G-59KJGZ93M6” was loaded even though its MIME type (“”) is not a valid JavaScript MIME type. [localhost:3000](http://localhost:3000/)
The script from “http://localhost:3000/_scripts/assets/5a3181dffd17faad.js?id=GTM-W8TCSQDL” was loaded even though its MIME type (“”) is not a valid JavaScript MIME type.

and in production it is a nightmare, we can't log anything there, browsers crash the whole app due to misbehaviour detection, js instead of json!

🛠️ To reproduce

https://baderidris.com/

🌈 Expected behavior

mime types are sensitive in browsers, please make sure your modifications to 3rd parties meet with expected types

ℹ️ Additional context

No response

[Bader-Idris]

this is how 500 errors appear in firefox browser:

[vite] new window visibility hidden b7d4ac5f-e0f6-4888-977a-6bbb2599571f:63:12
GET
http://localhost:5000/_nuxt/CoBY7EyH.js
NS_ERROR_CORRUPTED_CONTENT

GET
http://localhost:5000/_nuxt/D0wNMXVU.js
NS_ERROR_CORRUPTED_CONTENT

GET
http://localhost:5000/_nuxt/DDmImIu7.js
NS_ERROR_CORRUPTED_CONTENT

GET
http://localhost:5000/_nuxt/0B6d6b42.js
NS_ERROR_CORRUPTED_CONTENT

GET
http://localhost:5000/_nuxt/BcEwtVa7.js
NS_ERROR_CORRUPTED_CONTENT

Loading module from “http://localhost:5000/_nuxt/D0wNMXVU.js” was blocked because of a disallowed MIME type (“application/json”). contact
Loading failed for the module with source “http://localhost:5000/_nuxt/D0wNMXVU.js”. contact:1:35418
Loading module from “http://localhost:5000/_nuxt/CoBY7EyH.js” was blocked because of a disallowed MIME type (“application/json”). contact
Loading module from “http://localhost:5000/_nuxt/0B6d6b42.js” was blocked because of a disallowed MIME type (“application/json”). contact
Loading module from “http://localhost:5000/_nuxt/DDmImIu7.js” was blocked because of a disallowed MIME type (“application/json”). contact
Loading module from “http://localhost:5000/_nuxt/BcEwtVa7.js” was blocked because of a disallowed MIME type (“application/json”). contact
The resource at “https://www.googletagmanager.com/gtag/js?id=G-59KJGZ93M6” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. contact
The resource at “https://www.googletagmanager.com/gtm.js?id=GTM-W8TCSQDL” preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly. contact

and in server:

[request error] [unhandled] [GET] http://localhost/_nuxt/DDmImIu7.js
 H3Error: ENOENT: no such file or directory, open '/app/.output/public/_nuxt/DDmImIu7.js'
 at async open (node:internal/fs/promises:640:25)
 ... 2 lines matching cause stack trace ...
 at async Server.toNodeHandle (file:///app/.output/server/chunks/nitro/nitro.mjs:7858:7) {
 cause: Error: ENOENT: no such file or directory, open '/app/.output/public/_nuxt/DDmImIu7.js'
 at async open (node:internal/fs/promises:640:25)
 at async Object.readFile (node:internal/fs/promises:1287:14)
 at async Object.handler (file:///app/.output/server/chunks/nitro/nitro.mjs:7580:19)
 at async Server.toNodeHandle (file:///app/.output/server/chunks/nitro/nitro.mjs:7858:7) {
 errno: -2,
 code: 'ENOENT',
 syscall: 'open',
 path: '/app/.output/public/_nuxt/DDmImIu7.js'
 },
 statusCode: 500,
 fatal: false,
 unhandled: true,
 statusMessage: undefined,
 data: undefined
}
[request error] [unhandled] [GET] http://localhost/_nuxt/BcEwtVa7.js
 H3Error: ENOENT: no such file or directory, open '/app/.output/public/_nuxt/BcEwtVa7.js'
 at async open (node:internal/fs/promises:640:25)
 ... 2 lines matching cause stack trace ...
 at async Server.toNodeHandle (file:///app/.output/server/chunks/nitro/nitro.mjs:7858:7) {
 cause: Error: ENOENT: no such file or directory, open '/app/.output/public/_nuxt/BcEwtVa7.js'
 at async open (node:internal/fs/promises:640:25)
 at async Object.readFile (node:internal/fs/promises:1287:14)
 at async Object.handler (file:///app/.output/server/chunks/nitro/nitro.mjs:7580:19)
 at async Server.toNodeHandle (file:///app/.output/server/chunks/nitro/nitro.mjs:7858:7) {
 errno: -2,
 code: 'ENOENT',
 syscall: 'open',
 path: '/app/.output/public/_nuxt/BcEwtVa7.js'
 },
 statusCode: 500,
 fatal: false,
 unhandled: true,
 statusMessage: undefined,
 data: undefined
}

[Bader-Idris]

even installing @nuxtjs/partytown and enabling it didn't fix the promises blocking along with mime types

[harlan-zw]

Hey, thanks for the report.

Two separate things going on here:

1. Dev /_scripts/assets/*.js MIME "" warning — this was on us. The dev handler was returning the bundled script Buffer without a Content-Type header. Fixed in #748 (merged), will ship in the next release.

2. Production /_nuxt/*.js served as application/json + ENOENT for hashed Nuxt chunks — this is unrelated to @nuxt/scripts. Those are Nuxt's own client bundles, not bundled third-party scripts. The ENOENT from /app/.output/public/_nuxt/<hash>.js means your deployed .output/public/_nuxt directory is missing those files, or your reverse proxy / CDN is rewriting the response and clobbering the content-type. Common causes:

• Stale browser/CDN cache pointing at chunk hashes from a previous build (hard refresh, purge CDN).
• Reverse proxy (nginx/Caddy/Cloudflare) misconfigured to set application/json on /_nuxt/* or stripping/overriding the upstream Content-Type.
• Build output not fully copied into the deployment image (.output/public/_nuxt/ missing files).

Closing this once the next release lands, since the bit we own is fixed. If the prod side persists after a clean build + cache purge, please open a separate issue with your nginx/Caddy/Cloudflare config and we can take a look, but it'll most likely be a deploy-side fix.