standalone-typescript-language-features: is simulateWorkerReady the wrong way to configure getWorker, and is the 36.2.2/36.2.3 binder regression known?

[martinbu-tes]

Two related questions from a non-workbench ("standalone") setup using @codingame/monaco-vscode-standalone-typescript-language-features.

1. Are we doing something wrong with MonacoEnvironment.getWorker?

internal/common/workers.js's createWebWorker() waits for the worker to postMessage({type: "vscode-worker-ready"}) before using it. That signal is only ever sent by the library's own getWorkerUrl bootstrap blob — a worker we construct ourselves via MonacoEnvironment.getWorker never sends it, so getSyntacticDiagnostics/getSemanticDiagnostics hang forever:

window.MonacoEnvironment = {
  getWorker: (moduleId, label) => {
    if (label === "typescript" || label === "javascript") {
      // Hangs forever: this worker never posts "vscode-worker-ready".
      return new Worker(
        new URL(
          "@codingame/monaco-vscode-standalone-typescript-language-features/worker",
          import.meta.url
        ),
        { type: "module" }
      );
    }
    // ...
  },
};

For comparison, the Getting Started guide's "Adding languages" section (for plain monaco-editor, before the VSCode-API layer is introduced) shows getWorker returning new tsWorker() directly with no handshake of any kind needed — so this requirement seems specific to standalone-typescript-language-features's own createWebWorker, not something inherent to how Monaco workers normally work.

Our workaround is to manually dispatch that message ourselves, deferred so it fires after the library's own listener attaches:

function simulateWorkerReady(worker) {
  setTimeout(() => {
    worker.dispatchEvent(
      new MessageEvent("message", { data: { type: "vscode-worker-ready" } })
    );
  }, 0);
  return worker;
}

window.MonacoEnvironment = {
  getWorker: (moduleId, label) => {
    if (label === "typescript" || label === "javascript") {
      return simulateWorkerReady(
        new Worker(
          new URL(
            "@codingame/monaco-vscode-standalone-typescript-language-features/worker",
            import.meta.url
          ),
          { type: "module" }
        )
      );
    }
    // ...
  },
};

It works, but it relies on an internal implementation detail rather than a documented API. The demo's setup.common.ts uses getWorkerUrl/getWorkerOptions instead of getWorker for its workers, but never configures a "typescript"/"javascript" worker that way either (workbench mode gets TS support from the extension-host language server instead), so there's no reference example for this specific case. Is getWorker even supposed to work here, or is getWorkerUrl required — and if so, could you point to a working example for a non-esbuild bundler? (We tried the demo's getWorkerUrl/.url-on-worker-instance pattern and it didn't work under Vite 8/Rolldown — Worker instances there have no .url/.options properties.)

2. 36.2.2/36.2.3 regression: bundled compiler never binds source files

Separately, we bisected a real regression: getSemanticDiagnostics throws TypeError: Cannot read properties of undefined (reading 'get') on every version from 36.2.2 onward, but works correctly on 36.2.0 (and every version back to 25.0.0). npm diff between 36.2.0 and 36.2.2 shows createBinder() (TypeScript's own binder) was deleted from the bundled typescriptServices.js, and bindSourceFile() reduced to a no-op:

// 36.2.0 (working)
var binder = createBinder();
function bindSourceFile(file, options) {
  mark("beforeBind");
  binder(file, options);
  mark("afterBind");
  ...
}

// 36.2.2 / 36.2.3 (broken)
function bindSourceFile(file, options) {
  mark("beforeBind");
  mark("afterBind");
  ...
}

Is this a known issue? We've pinned to 36.2.0 as a workaround. Happy to open this as a separate bug report with a minimal repro if that's more useful than a discussion thread.

[CGNonofr]

Are we doing something wrong with MonacoEnvironment.getWorker?

The worker logic changed quite a lot this year, with monaco-editor being often late compared to VScode changes

Anyway, I would recommend only using getWorkerUrl & getWorkerOptions, which are working for all workers (the editor worker, the language workers AND the extension host worker, loaded from an iframe)

Also, it uses a blob worker loading that script to support cross-origin workers. And finally, it adds the vscode-worker-ready message sender to the worker.

I'm not sure how it works in monaco-editor alone 🤔

2. 36.2.2/36.2.3 regression: bundled compiler never binds source files

Indeed, it seems that it's caused by the rollup update, especially rollup/rollup#6065 which analyse the source code more in depth and now detects for some reason this method as pure 🤔

They've immediately released a patch though to revert that behavior. Rollup was updated in this repo and it's already building, a new version will be deployed soon with the fixed version

[martinbu-tes]

Thanks for the quick and detailed reply on both!

getWorkerUrl/getWorkerOptions: switched over and it works great - no more manual "vscode-worker-ready" handshake needed. For anyone else hitting this with Vite, the piece we were missing was Vite's ?worker&url import suffix, which bundles the target as a worker and gives back the built URL as a string (rather than a Worker instance), which is what getWorkerUrl needs:

import typescriptWorkerUrl from "@codingame/monaco-vscode-standalone-typescript-language-features/worker?worker&url";
import editorWorkerUrl from "monaco-editor/esm/vs/editor/editor.worker.js?worker&url";
import textMateWorkerUrl from "@codingame/monaco-vscode-textmate-service-override/worker?worker&url";

const workerUrls: Partial<Record<string, string>> = {
  typescript: typescriptWorkerUrl,
  javascript: typescriptWorkerUrl,
  TextEditorWorker: editorWorkerUrl,
  editorWorkerService: editorWorkerUrl,
  TextMateWorker: textMateWorkerUrl,
};

window.MonacoEnvironment = {
  getWorkerUrl: (moduleId, label) => {
    const url = workerUrls[label];
    if (url != null) return url;
    throw new Error(`Unimplemented worker ${label} (${moduleId})`);
  },
  getWorkerOptions: () => ({ type: "module" }),
};

Confirmed working end-to-end for both the editor worker and the TS/JS language worker, no fallback-to-main-thread warnings.

36.2.2/36.2.3 regression: confirmed fixed in 36.2.4 - npm diff shows createBinder() restored, and re-tested our full repro (both getSemanticDiagnostics directly and through the real editor's marker service) with no crash. Bumped our pin from 36.2.0 to 36.2.4. Thanks for turning that around so fast!