[Bug]: playground - Published package references monaco workers via hard-coded /assets/... URLs, breaking every consumer

[dalbrx-nitrobox]

Describe the bug

Since @typespec/playground@0.17.1, the published package loads its monaco workers from
hard-coded absolute URLs pointing into the package's own build output layout:

node_modules/@typespec/playground/dist/editor.worker-Biegl0p7.js

function WorkerWrapper(options) {
	return new Worker("/assets/editor.worker-CBxI71al.js", { name: options?.name });
}

node_modules/@typespec/playground/dist/json.worker-j8mDmDqS.js

	return new Worker("/assets/json.worker-BMpfVdM-.js", { name: options?.name });

Both files exist in the package (dist/assets/editor.worker-CBxI71al.js,
dist/assets/json.worker-BMpfVdM-.js), but the URL is a site-root absolute path, so it only
resolves if the consuming app happens to serve the package's dist/assets folder at /assets.
In any downstream app (and with any non-/ base path), GET /assets/editor.worker-CBxI71al.js
falls through to the SPA fallback and returns index.html.

In 0.17.0 the workers were still plain ?worker imports that the consumer's bundler resolved:

const { default: editorWorker } = await import("monaco-editor/esm/vs/editor/editor.worker?worker");

Actual behavior

The monaco workers never start and the console shows:

Uncaught SyntaxError: Unexpected token '<'
    at http://localhost:5173/assets/editor.worker-CBxI71al.js
Uncaught [object ErrorEvent]
    at .../monaco-editor/esm/vs/base/common/errors.js

Expected behavior

The worker assets are resolved relative to the module that requests them (e.g. via
new URL(..., import.meta.url) or by leaving the monaco-editor/...?worker imports to the
consuming bundler), so they keep working regardless of where the consumer serves the app from
and under any base.

Affected versions

version	worker loading
0.17.0, 0.17.1-dev.0, 0.17.1-dev.1	?worker import, works
0.17.1-dev.2, 0.17.1, 0.17.2-dev.1, 0.18.0-dev.2	hard-coded /assets/..., broken

So the regression was introduced between 0.17.1-dev.1 and 0.17.1-dev.2, most likely by the
change that made the playground's own build pre-bundle the monaco workers instead of re-exporting
the ?worker imports.

Workaround for consumers

Serve the package's asset folder from the site root, e.g. as a small Vite plugin:

const assetsDir = join(dirname(require.resolve("@typespec/playground")), "assets");
// dev: middleware serving /assets/<file> from assetsDir
// build: this.emitFile({ type: "asset", fileName: `assets/${file}`, source: readFileSync(...) })

Reproduction

1. Create a Vite app that depends on @typespec/playground@0.17.1 (same setup as
   packages/playground-website) and calls registerMonacoDefaultWorkersForVite().
2. Run the dev server or serve a production build.
3. Open the playground and watch the browser console.

Checklist

• Follow our Code of Conduct
• Check that there isn't already an issue that request the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion.
• The provided reproduction is a minimal reproducible example of the bug.

[github-actions]

🎯 Issue Triage

The published @typespec/playground package emits Monaco worker URLs as site-root /assets/... paths, so workers fail for downstream consumers that do not expose the package assets there. This is a packaging regression beginning with 0.17.1-dev.2 and affects custom deployments, especially applications hosted under a non-root base path.
Category: Bug
Area: ui:playground

⚠️ No reproduction provided. A minimal repro would help diagnose this issue.

🔍 Analysis

The affected component is @typespec/playground's Vite/Monaco worker registration and published bundle output. The evidence points to worker imports being pre-bundled into wrappers containing absolute /assets/... URLs rather than remaining consumer-resolvable ?worker imports or module-relative URLs. The reporter provides a precise affected-version range, runtime errors, and procedural Vite reproduction; the included JavaScript and TypeScript snippets are generated output and workaround code, not TypeSpec reproduction input. Searches for Monaco worker URLs, registerMonacoDefaultWorkersForVite, and playground asset/base-path failures found no issue describing the same root cause.

📝 Suggested next steps

• Reproduce with a minimal Vite consumer using @typespec/playground@0.17.1 and a non-root base.
• Identify the build change between 0.17.1-dev.1 and 0.17.1-dev.2 that caused worker pre-bundling.
• Emit module-relative worker URLs or preserve consumer-side ?worker resolution, with a package-consumer regression test.

Generated by Agentic Triage