Build output should use .js extensions

[GeoffreyBooth]

Describe the bug

After updating to the newest SvelteKit yesterday, my app fails to load. I’m using adapter-static to generate a SvelteKit app that’s hosted by my company’s CDN. Once it's hosted there, I've been getting this error in Chrome:

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of “application/octet-stream”. Strict MIME type checking is enforced for module scripts per HTML spec.

caught (in promise) TypeError: Failed to fetch dynamically imported module: https://…/_app/immutable/entry/start.bbece0d7.mjs

Apparently my CDN doesn’t know that .mjs files need to be served with the Content-Type header text/javascript. (See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules#aside_%E2%80%94_.mjs_versus_.js.) While this is unfortunate, I’m not in a position to fix a bug in my company’s CDN.

As an alternative, SvelteKit could output all its built JavaScript as .js files. There’s not really any reason to use .mjs; browsers don’t know or care about file extensions, only Content-Type headers, and CDNs and servers like Apache and Nginx are very likely to serve .js files with a JavaScript MIME type. Have the build script output build/package.json that contains {"type": "module"} and the build output can be run by Node as well without issues.

Reproduction

https://stackblitz.com/edit/sveltejs-kit-template-default-8dvxxy?file=svelte.config.js&terminal=dev

Just use adapter-static as your adapter and run npm run build. All the JavaScript files inside build/ will have .mjs extensions.

Logs

Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "application/octet-stream". Strict MIME type checking is enforced for module scripts per HTML spec.

Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://<omitting…>/_app/immutable/entry/start.bbece0d7.mjs

System Info

System:
    OS: macOS 12.6
    CPU: (16) x64 Intel(R) Xeon(R) W-3223 CPU @ 3.50GHz
    Memory: 2.05 GB / 48.00 GB
    Shell: 5.9 - /usr/local/bin/zsh
  Binaries:
    Node: 19.3.0 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.4.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 110.0.5481.100
    Chrome Canary: 112.0.5613.0
    Edge: 109.0.1518.78
    Firefox: 108.0.1
    Firefox Developer Edition: 110.0
    Safari: 16.2
  npmPackages:
    @sveltejs/adapter-static: ^2.0.1 => 2.0.1
    @sveltejs/eslint-config: github:sveltejs/eslint-config => 5.8.0
    @sveltejs/kit: ^1.8.3 => 1.8.3
    svelte: ^3.55.1 => 3.55.1
    vite: ^4.1.4 => 4.1.4

Severity

blocking an upgrade

Additional Information

I see these mentions of .mjs in the SvelteKit code:

kit/packages/kit/src/runtime/server/page/render.js

Lines 276 to 279 in 8c21383

	// we use modulepreload with the Link header for Chrome, along with
	// <link rel="preload"> for Safari. This results in the fastest loading in
	// the most used browsers, with no double-loading. Note that we need to use
	// .mjs extensions for `preload` to behave like `modulepreload` in Chrome

kit/packages/kit/src/exports/vite/index.js

Lines 519 to 522 in 8c21383

	// we use .mjs for client-side modules, because this signals to Chrome (when it
	// reads the <link rel="preload">) that it should parse the file as a module
	// rather than as a script, preventing a double parse. Ideally we'd just use
	// modulepreload, but Safari prevents that

But I don’t know where this information comes from; it conflicts with my understanding of how browsers determine whether to treat a JavaScript URL as a module. cc @Rich-Harris as you apparently wrote these comments, and made these changes 4 days ago. I’d guess that #8957 is what broke my site.

[eltigerchino]

This will be fixed by #9179

[dummdidumm]

Closing as duplicate of #9141