Is there a way to disable injection of client.ts for a particular entry?

[jraoult]

I'm trying to migrate a project using AudioWorklet written in typescript from Webpack. As noted before: #9606 (comment) the injection of Vite's client module is not compatible with the AudioWorkletGlobalScope that lacks URL, and as noted here: #13985 the workaround consisting in treating the worklet code as a static resource is not ideal (in my case I need both dependencies and transpilation from Typescript).

Another approach would be to disable the injection of client.ts since HMR doesn't mean anything in a worklet anyway. Is there a way to selectively disable the injection of client.ts. Ideally, I would want to keep it for other parts of the app to leverage HMR in the UI code, for example.

[jraoult]

I found a workaround for anyone interested, but it is convoluted:

• replace vite with a combination of vite build --watch and vite preview. It prevents the injection client.ts. It seems like disbaling HMR in the dev server was not enough.
• use the snippet below to collect the worklet processor script URL:

const processorUrl = () => {
  // The only way to get a transformed chunked URL is to abuse of the worker
  // support. The supported syntax can be found here: https://github.com/vitejs/vite/blob/b9ee620108819e06023e4303af75a61d3e4e4d76/packages/vite/src/node/plugins/workerImportMetaUrl.ts#L140.
  //
  // This class shadows the actual Worker class in the local scope, so we can
  // collect the chunk URL without running the code in an actual worker (which
  // would error).
  class Worker {
    path;

    constructor(path: URL) {
      this.path = path;
    }
  }

  return new Worker(new URL("./processor.ts", import.meta.url)).path;
};

I still think Vite should natively support AudioWorklet. I know Parcel does, and there is rollup plugin that does too.

[hi-ogawa]

I think the injection of @vite/client is not always done by vite, but it's likely triggered by other plugins injecting import.meta.hot....
For example, for the case of the original issue #9606, preact plugin applies preact-refresh transform for all ts, tsx, js, jsx files by default, thus injecting import.meta.hot to audioworklet src file as well, which then triggers vite's @vite/client injection.
https://github.com/preactjs/preset-vite/blob/aa534d61a35cfb90ec731d8f18f734d32d578467/src/index.ts#L105-L108

So, I think workaround for preact plugin could be to explicitly choose only .tsx file to transform, for example by:

export default defineConfig({
  // or use "exclude" option to exclude only audioworklet related files?
  plugins: [preact({ include: /\.tsx$/ })]
})

I'm not sure which plugin you're using but if its react plugin, then it could be same:
https://github.com/vitejs/vite-plugin-react/blob/3748fc7493cf0a07a2ae275fbd1ae035f01010cc/packages/plugin-react/src/index.ts#L94

---

Coincidentally, I also had vite project using audioworklet, so I was curious about this issue and also went back to mine.
What I was doing originally was to run tsup --watch to bundle audioworklet entrypoint separately, but it seems now I can just use some-entry-file?worker&url to let vite transpile/bundle together with main app hi-ogawa/toy-metronome#34
(note that my project doesn't use react for UI, so things might be a bit different).

[jraoult]

@hi-ogawa interesting... it makes sense. Let me try that, I'm indeed using the "@vitejs/plugin-react-swc plugin, so it might be the reason.

[jraoult]

Hmm @hi-ogawa still not that. I think the problem is here:

vite/packages/vite/src/node/plugins/importAnalysis.ts

Line 716 in c3b55c4

if (needQueryInjectHelper) {

where the client.ts module is imported.

So, back to Parcel for me. I also thought about transpiling the audioworklet out of band (as you described with tsup), but it is less practical since I have to maintain the path of the different worklet modules manually.

[hi-ogawa]

hmm, that's unfortunate, but thanks for experimenting on your side.
My demo project is really a simplest possible vite + audioworklet demo, so it was okay, but maybe for more realistic project, there are more factors needs to be taken in account to workaround vite's client helper.

I'm still curious what's the exact condition for vite to make this decision (and also why), so I think I'll experiment a bit further when I have time and maybe will comment back to here if I find something.
Btw, I didn't know about Percel supporting this use case. Thanks for sharing and also initiating the discussion!

[hi-ogawa]

I was looking it further (btw, thanks for the pointer about needQueryInjectHelper) and it looks like vite needs this only when there is a dynamic import which is not possible to statically analyze. There is this if-branch before going into the block of needQueryInjectHelper = true.

vite/packages/vite/src/node/plugins/importAnalysis.ts

Lines 482 to 484 in c3b55c4

	// static import or valid string in dynamic import
	// If resolvable, let's resolve it
	if (specifier) {

My quick repro also indicates so hi-ogawa/toy-metronome#36.
For example, I'm checking how vite transforms code from http://localhost:5173/src/audioworklet/index.ts?type=module&worker_file

Original code

import { METRONOME_PROCESSOR_NAME } from "./common";
import { MetronomeProcessor } from "./metronome";

import { repro } from "./repro";

function reproOk() {
  import("./repro")
}

// this triggers injection of `__vite__injectQuery`
function reproNotOk() {
  import("./repro".slice())
}

registerProcessor(METRONOME_PROCESSOR_NAME, MetronomeProcessor);

"@vite/client" Injected

import { injectQuery as __vite__injectQuery } from "/@vite/client";import "/node_modules/.pnpm/vite@4.4.9/node_modules/vite/dist/client/env.mjs"
import { METRONOME_PROCESSOR_NAME } from "/src/audioworklet/common.ts";
import { MetronomeProcessor } from "/src/audioworklet/metronome.ts";
import { repro } from "/src/audioworklet/repro.ts";
function reproOk() {
  import("/src/audioworklet/repro.ts");
}
function reproNotOk() {
  import(__vite__injectQuery("./repro".slice(), 'import'));
}
registerProcessor(METRONOME_PROCESSOR_NAME, MetronomeProcessor);

"@vite/client" not injected

import "/node_modules/.pnpm/vite@4.4.9/node_modules/vite/dist/client/env.mjs"
import { METRONOME_PROCESSOR_NAME } from "/src/audioworklet/common.ts";
import { MetronomeProcessor } from "/src/audioworklet/metronome.ts";
import { repro } from "/src/audioworklet/repro.ts";
function reproOk() {
  import("/src/audioworklet/repro.ts");
}
registerProcessor(METRONOME_PROCESSOR_NAME, MetronomeProcessor);

So, maybe your code (or dependency chain from your audioworklet entrypoint?) might include such dynamic import somewhere.

Also I found that audioworklet environment doesn't support dynamic import. If I actually try to call it, then I see following error:

Uncaught (in promise) TypeError: import() is disallowed on WorkletGlobalScope.

I'm not trying to convert you to use vite or anything, so feel free to ignore.
I just wanted to have a better understanding for my own sake and maybe it'll help other people coming across with similar niche issues.

[jraoult]

So, maybe your code (or dependency chain from your audioworklet entrypoint?) might include such dynamic import somewhere.

@hi-ogawa very good intuition; look at that:

https://github.com/superpoweredSDK/web-audio-javascript-webassembly-SDK-interactive-audio/blob/50b892679005bf6c4ba887963d599c881dca3111/Superpowered.js#L742-L746

So even if the code is not actually used, Vite decorates with hits needQueryInjectHelper and includes the client file that then creates an error when referencing the URL global object. I removed that dependency and indeed the needQueryInjectHelper ariable is now false.... but the client.ts is still imported 🤦‍♂️ So I think I was wrong about query inject helper; the real issue is the import of client.ts... and I still don't know why and by which part of Vite it is done.