aws / aws/graph-explorer

Monaco editor runtime is fetched from a public CDN at a version we don't control

Open
#2,161 0 comments 0 reactions 0 assignees View on GitHub
internal query editor tech debt
Dominant language
TypeScript
Stars
481
Forks
108
Avg merge
6d 8h
Merged PRs (30d)
5

Description

The `monaco-editor` version declared in `packages/graph-explorer/package.json` has no effect on the editor users actually get. The runtime editor is fetched from a public CDN at a version pinned inside a transitive dependency.

## What's actually happening

`src/components/CodeEditor.tsx` imports only from `@monaco-editor/react`. That package declares `monaco-editor` as a *peer* dependency, used for types, and loads the real editor at runtime through `@monaco-editor/loader`, which hardcodes its own CDN URL. In `@monaco-editor/loader` 1.7.0 that URL is `https://cdn.jsdelivr.net/npm/monaco-editor@0.55.1/min/vs`.

There is no `loader.config()` call, no `MonacoEnvironment`, no `getWorker`, and no `?worker` import anywhere in `src/`, `vite.config.ts`, or `index.html`, so the loader's default applies. I confirmed the built bundle contains exactly that jsDelivr URL and that monaco itself is not bundled, while `node_modules` resolves `monaco-editor` to 0.56.0.

## Why it matters

- **The declared version is misleading.** Bumping `monaco-editor` (0.55.1 to 0.56.0 in #2156, for instance) changes nothing users see. Reviewing that bump gives false confidence.
- **A future `@monaco-editor/loader` or `@monaco-editor/react` bump silently changes the editor version**, with no diff in our manifests to review.
- **The editor loads from the public internet.** Any deployment without egress to `cdn.jsdelivr.net` — air-gapped, VPC-only with no NAT, or a restrictive CSP — should fail to load the editor, which would take out the query editor and the "Error Details" and "Raw response" views. Worth noting this is inferred from the loading mechanism, not something I reproduced; confirming it against a blocked-egress environment is the first thing this issue should do.
- **98 MB of `monaco-editor` sits in the prod dependency closure** and is never served, because it's declared in `dependencies` and the image builds with `pnpm install --prod`.

## Work

Decide whether the editor should be self-hosted. If yes, call `loader.config({ paths: { vs: ... } })` (or `loader.config({ monaco })`) against a copy served from our own assets, so the version comes from the lockfile and the editor works without internet access. That would make the `monaco-editor` dependency real rather than types-only, and the declared version would finally match what runs.

If self-hosting isn't wanted, the alternative is to pin the CDN version explicitly through `loader.config` so at least a version change is visible in a diff, and to document that egress to the CDN is a deployment requirement.

## Acceptance

The editor version users get is traceable to something in this repo, and the deployment requirement is either removed or written down.

> [!IMPORTANT]
> Internal only — this issue is maintained by the core team and is not accepting external contributions.

Contributor guide

Open the contributing guide

Research direction

Start with packages/graph-explorer/package.json, src/components/CodeEditor.tsx, vite.config.ts, and index.html; verify the built bundle and dependency resolution described in the issue. Confirm the blocked-egress impact, then determine whether self-hosting or explicit CDN pinning fits the project. Done means the runtime version is traceable to this repository and the deployment requirement is removed or documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
react, typescript
Domain
devops, frontend
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.