dev and prod have inconsistent content-types for .ts files

[kgullion]

Describe the bug

.ts files imported via the *?url hook have different content-types. In dev, the .ts file is served with the content-type application/javascript while in prod it is served as a video/mp2t dataUri.

Related: #2642

Reproduction

https://github.com/kgullion/vite-typescript-audio-worklet-example

The first 2 lines of src/main.ts are sufficient for reproduction. I've included a short example for additional context.

npm run dev works as expected but npm run build && npm run serve returns the incorrect Content Type for the AudioWorklet. This causes Uncaught (in promise) DOMException: The user aborted a request. in the browser (see: https://stackoverflow.com/a/51469624/992385).

System Info

System:
    OS: Linux 5.12 undefined
    CPU: (4) x64 Intel(R) Core(TM) i3-4010U CPU @ 1.70GHz
    Memory: 346.62 MB / 3.74 GB
    Container: Yes
    Shell: 5.1.8 - /bin/bash
  Binaries:
    Node: 16.2.0 - /usr/bin/node
    Yarn: 1.22.10 - /usr/bin/yarn
    npm: 7.15.1 - /usr/bin/npm
  Browsers:
    Brave Browser: 91.1.25.68
    Chromium: 91.0.4472.77
    Firefox: 89.0
  npmPackages:
    vite: ^2.4.0 => 2.4.1

Used Package Manager

npm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.

[patak-dev]

Is this using vite preview when serving the built app? @kgullion what is the fix you are looking for here?
Is it to make vite preview also interpret .ts files as application/javascript?
I don't know if this is a good idea because people could think that their deployed sites will work in the same way. Is there a real issue with these being different?

[GormanFletcher]

I encountered this problem when writing a custom service worker in TypeScript, doing something like this:

import serviceWorkerPath from './serviceworker.ts?url';
navigator.serviceWorker.register(serviceWorkerPath);

Everything worked fine with vite dev, but when I used assets from vite build I got a runtime error registering my service worker because the production build imports the file as a base64-encoded value, rather than as the URL path the file is located at.

Initially, I came to this issue, since I expected this to work the same in the dev server and a production build. However, I realized this was the wrong way to approach compiling a custom service worker in the first place. Even if the import returned a file path in both situations, it wouldn't get a consistent filename in the prod build - it'd have the content hash in the filename. That means rather than upgrading the service worker when it changed, it'd install a new one side-by-side. And besides that, service workers currently don't support importing ES modules, so for my case I need a separate build pipeline regardless.

It'd be nice if Vite offered convenience tools for writing custom service workers, but in the end the right answer for me, rather than faulting this bug, was to create a separate Vite config file for my service worker and add separate build commands for it.

[patak-dev]

Have you checked https://github.com/antfu/vite-plugin-pwa? If using Workbox is not good in your case, at least it may be interesting how they solved the service worker handling in Vite.

Importing a .ts by URL is not right as you discover, maybe there could be a warning in dev for this case. But I think it isn't possible, since .ts could be a valid video format.

Let's close this issue for the moment, and wait for feedback in case others find problems with the current approach. Thanks for bringing this up.