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

[koushik717]

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 build — editor.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.

[vercel]

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

A member of the Team first needs to authorize it.

[gregfurman]

Thanks for the changes here @koushik717! I verified this locally on mac with a sandboxed firefox process without network access and it worked like a charm ✨

Once CI is 🟢 this looks good to ship!

[koushik717]

Thanks for the changes here @koushik717! I verified this locally on mac with a sandboxed firefox process without network access and it worked like a charm ✨

Once CI is 🟢 this looks good to ship!

@gregfurman The cypress failure appears to be a pre-existing flaky test it's also failing on unrelated PRs (mk/durable-tasks-as-operator, belanger/operators) at the same time with no overlap with this change. All other 25 CI checks are green. Happy to have someone re-run cypress or merge if the flakiness is known.

[mrkaye97]

Hi @koushik717 - FYI that we needed to revert this change here because it unfortunately broke JSON schema preview / autocomplete in the trigger runs form in production. I think this likely has to do with how assets are served in our production environments, but I didn't dig too deeply. Feel free to put up a re-apply of the PR with a fix if you'd like to investigate, and sorry for the churn here!

[koushik717]

@mrkaye97 Thanks for the heads up and sorry for the breakage! The root cause was Vite's ?worker suffix, which emits workers as separate JS chunk files fetched by URL at runtime. In production those cross-origin worker fetches get blocked by CORS headers on the asset server, which killed the JSON schema autocomplete. I've put up #4579 which switches to ?worker&inline so workers are bundled as blob URLs instead, no cross-origin fetch at runtime. Good night!