Symptom
The browser console is flooded with repeated errors whenever a Monaco
editor mounts (XComs page, Audit Log, DAG code page, etc.), in dev builds, not blocking for 3.2.2 release but probably work fixing for a clean dev end.
```
stableEditorScroll-…:11511 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'toUrl')
at FileAccessImpl.toUri (stableEditorScroll-…:11511:34)
at FileAccessImpl.asBrowserUri (stableEditorScroll-…:11484:20)
at editor.api-…:9016:45
at new Promise ()
at EditorSimpleWorker.$loadForeignModule (editor.api-…:9011:10)
```
The editor still renders and basic features work because of Monaco's
silent fall-back paths, but every editor instance produces a handful of
these unhandled rejections.
Root cause
`EditorSimpleWorker.$loadForeignModule` resolves the foreign module
URL through `FileAccess.asBrowserUri(moduleId)`, which ends up at
`FileAccessImpl.toUri`. That method takes a second argument
`moduleIdToUrl` and calls `moduleIdToUrl.toUrl(uriOrModule)`. Monaco's
CDN/AMD build supplies a `require` object with a `toUrl` method as
`moduleIdToUrl`; the local-ESM build introduced in #66647 does not — so
`moduleIdToUrl` is undefined and `.toUrl` throws.
The errors were latent before but became visible recently: with PR
#67316 fixing the dev-mode worker URL (via `server.origin`), workers
actually load now, so they reach the foreign-module loader and trip on
this immediately. In production they have always been firing too,
just less noticeably because no one was looking.
Possible fixes
- Provide a `foreignModuleFactory` so `$loadForeignModule` never falls
through to the AMD-require path; this is the approach the
monaco-editor docs recommend for non-AMD setups. - Or polyfill `globalThis.require = { toUrl: (id) => new URL(id, location.href).toString() }` inside the worker bootstrap.
Either fix belongs in `MonacoEditor/configureMonaco.ts` (or a worker
init shim alongside it), not in `RenderedJsonField.tsx`.
Related: #67316 (the expand/collapse fix where this issue surfaced).
Symptom
The browser console is flooded with repeated errors whenever a Monaco
editor mounts (XComs page, Audit Log, DAG code page, etc.), in dev builds, not blocking for 3.2.2 release but probably work fixing for a clean dev end.
```
stableEditorScroll-…:11511 Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'toUrl')
at FileAccessImpl.toUri (stableEditorScroll-…:11511:34)
at FileAccessImpl.asBrowserUri (stableEditorScroll-…:11484:20)
at editor.api-…:9016:45
at new Promise ()
at EditorSimpleWorker.$loadForeignModule (editor.api-…:9011:10)
```
The editor still renders and basic features work because of Monaco's
silent fall-back paths, but every editor instance produces a handful of
these unhandled rejections.
Root cause
`EditorSimpleWorker.$loadForeignModule` resolves the foreign module
URL through `FileAccess.asBrowserUri(moduleId)`, which ends up at
`FileAccessImpl.toUri`. That method takes a second argument
`moduleIdToUrl` and calls `moduleIdToUrl.toUrl(uriOrModule)`. Monaco's
CDN/AMD build supplies a `require` object with a `toUrl` method as
`moduleIdToUrl`; the local-ESM build introduced in #66647 does not — so
`moduleIdToUrl` is undefined and `.toUrl` throws.
The errors were latent before but became visible recently: with PR
#67316 fixing the dev-mode worker URL (via `server.origin`), workers
actually load now, so they reach the foreign-module loader and trip on
this immediately. In production they have always been firing too,
just less noticeably because no one was looking.
Possible fixes
through to the AMD-require path; this is the approach the
monaco-editor docs recommend for non-AMD setups.
Either fix belongs in `MonacoEditor/configureMonaco.ts` (or a worker
init shim alongside it), not in `RenderedJsonField.tsx`.
Related: #67316 (the expand/collapse fix where this issue surfaced).