hub-client: fix source editor failing to appear on project open (bd-eakukmlr, bd-yvz2xqrm)#411
Merged
Merged
Conversation
Opening a project sometimes showed a working preview but an empty Monaco editor until refresh. Root cause: useAutomergeSync's reconciliation effect only re-ran on [currentFile, fileContents, replayIsActive] — editor mount was not a trigger; onEditorMount just stored the ref. @monaco-editor/react creates the editor in a passive effect but delivers onMount one commit later, so when file content landed in the same React commit that created the editor (offline-first connect + straggler docs arriving while the CDN-loaded Monaco initializes), the reconciliation ran before the ref was set, took the "Monaco isn't ready" branch (React state only — hence the working preview), and never ran again on a quiescent document. The uncontrolled editor (defaultValue) stayed blank. Fix: bump an editorMountGen counter in onEditorMount and include it in the reconciliation deps, so every editor instance gets a reconcile pass once reachable. A counter rather than a boolean so key-based remounts (file switches) re-reconcile the fresh instance even while editorRef still points at the disposed previous editor. Two regression tests: mount-after-content-arrival and fresh-instance key remount; both fail without the fix.
… (bd-yvz2xqrm)
Nothing configured @monaco-editor/loader, so it fell back to fetching
Monaco from cdn.jsdelivr.net at runtime. In an offline-first app that
made the core editor hard-depend on a third-party CDN: with the CDN
slow, blocked, or the browser offline, the source pane sat at the
wrapper's "Loading..." placeholder forever (the editor was never
created) while the preview — fed by the local websocket — worked.
A distinct failure mode from bd-eakukmlr's created-but-empty race,
with the same user-visible flavor.
Fix: monacoSetup.ts imports monaco-editor from node_modules (the dep
was already declared, types-only until now), wires the standard Vite
worker setup via self.MonacoEnvironment, and calls
loader.config({ monaco }) — loader.init() then resolves the bundled
instance without injecting any CDN script. Editor.tsx (the only
MonacoEditor consumer) imports it for its side effects. The PWA now
precaches Monaco with the rest of the app (precache 75 → 166 entries).
Regression test: e2e/monaco-bundled.spec.ts blocks cdn.jsdelivr.net
outright and asserts the editor still renders the document and that
zero CDN requests are attempted. Fails against the pre-fix build
(editor never appears), passes with the fix; project-loading and
projects-home specs stay green on bundled Monaco.
Note: the mermaid renderer still lazy-imports from jsDelivr when a
document uses mermaid; that is a separate, narrower dependency and is
out of scope here.
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
…OS CI) Bundling Monaco (9d6a764) grew the rollup module graph past the ~2 GB default Node heap on the 7 GB macOS runners; `vite build` died with "Reached heap limit" during transform. Reproduced locally with --max-old-space-size=2048; 4096 builds in ~18 s. Applied to `build` and `build:local-prod` (the two scripts that invoke `vite build`), so every environment gets the headroom, not just CI.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Opening a project sometimes left the source editor unusable while the preview worked, and a refresh always fixed it. This turned out to be two separate bugs; this PR fixes both.
Empty editor (
bd-eakukmlr)The editor mounts but shows an empty document. The sync hook (
useAutomergeSync) copies content into Monaco when the file or its contents change — but not when the editor becomes ready. Monaco'sonMountfires one React commit after the editor is created, so content arriving in that window went into React state (hence the working preview) and was never retried; the editor is uncontrolled, so nothing else fills it.Fix:
onEditorMountbumps a counter the sync effect depends on, giving every newly mounted editor a catch-up pass (a counter, not a boolean, because file switches remount the editor). Two hook-level regression tests fail without the fix.Editor stuck at "Loading..." (
bd-yvz2xqrm)The editor is never created.
@monaco-editor/loaderwas unconfigured, so it downloaded Monaco from the jsDelivr CDN at page load — if the CDN is slow, blocked, or the browser offline, no editor.Fix: Monaco is now bundled (
monacoSetup.ts: web workers +loader.config({ monaco })), so no CDN request is made and the PWA precaches the editor for offline use. A new e2e spec blockscdn.jsdelivr.netand asserts the editor still renders with zero CDN requests; it fails against the previous build.Verification
npm run build:allgreenmonaco-bundled,project-loading,projects-homepass against a live hub