Skip to content

fix(dashboard): bundle Monaco editor instead of fetching from CDN#4247

Open
koushik717 wants to merge 6 commits into
hatchet-dev:mainfrom
koushik717:fix/bundle-monaco-editor
Open

fix(dashboard): bundle Monaco editor instead of fetching from CDN#4247
koushik717 wants to merge 6 commits into
hatchet-dev:mainfrom
koushik717:fix/bundle-monaco-editor

Conversation

@koushik717

@koushik717 koushik717 commented Jun 22, 2026

Copy link
Copy Markdown

Fixes #3703

@monaco-editor/react defaults to loading Monaco's AMD bundle from cdn.jsdelivr.net at runtime, which breaks the editor in air-gapped or restricted-network self-hosted deployments.

What changed

  • Added monaco-editor as a direct dependency.
  • Added frontend/app/src/lib/monaco-environment.ts, imported once from code-editor.tsx, which:
    • registers a MonacoEnvironment.getWorker using Vite's native ?worker import for the editor and JSON workers (the only language currently wired up via configureJsonSchema), and
    • calls loader.config({ monaco }) so @monaco-editor/react resolves the bundled instance instead of injecting a CDN <script> tag.

Notes for reviewers

  • The built bundle still contains the literal jsdelivr URL string — that's @monaco-editor/loader's default config object, never reached once loader.config({ monaco }) runs. Confirmed via build inspection and network monitoring that this is dead code, not a live network call.
  • Importing the full monaco-editor package auto-registers a few language workers we don't currently use (css/html/ts) alongside json/editor — expected behavior of the package itself, not something this PR controls. Can follow up with trimming if bundle size is a concern.
  • There wasn't an existing Vite worker pattern in this codebase to follow, so I used Vite's built-in ?worker suffix, which needs no extra plugin.

Testing

  • pnpm run typecheck — no new errors (pre-existing failures are unrelated missing-codegen files, confirmed against main).
  • vite buildeditor.worker and json.worker are emitted as separate chunks; loader.config({ monaco }) runs at build time.
  • Manual check in the browser with the editor mounted standalone: renders correctly with live JSON syntax highlighting, typing works, and I inspected every network request the page made (filtered for jsdelivr and cdn.*) — zero matches. No console errors beyond standard dev-mode noise.

AI disclosure (per AI_POLICY.md): I used an AI coding assistant for parts of this change and reviewed/tested everything above myself before opening this PR.

@monaco-editor/react defaults to loading Monaco's AMD bundle from
cdn.jsdelivr.net at runtime, which breaks the editor in air-gapped or
restricted-network self-hosted deployments.

Adds monaco-editor as a direct dependency and configures Vite's native
?worker imports for the editor/json workers plus loader.config({ monaco })
so @monaco-editor/react resolves the bundled instance instead of injecting
a CDN script tag.

Fixes hatchet-dev#3703
@vercel

vercel Bot commented Jun 22, 2026

Copy link
Copy Markdown

@koushik717 is attempting to deploy a commit to the Hatchet Team on Vercel.

A member of the Team first needs to authorize it.

@github-actions github-actions Bot added the dashboard Related to the Hatchet dashboard label Jun 22, 2026
koushik717 and others added 5 commits June 24, 2026 14:18
…itor types

@monaco-editor/react's Monaco type resolves through
monaco-editor/esm/vs/editor/editor.api. Before monaco-editor was a real
dependency, that import was unresolvable and TS silently treated downstream
usages as untyped, masking an implicit-any on this filter callback. Now
that monaco-editor is bundled, the real types apply and the implicit-any
needs an explicit annotation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dashboard Related to the Hatchet dashboard

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEAT] Bundle monaco editor

1 participant