Git

Milestone

No milestone

Labels

Assignees

lukaas-007

Linked items

Loading…

Projects

Loading…
lukaas-007 commented

Editor roadmap

What stands between the React editor and daily-driving it, in the order I'd build it. Every item links to its issue, which carries the detail — this file is only the sequence and the reasoning behind it.

Sizes are rough gut calls from reading the code, not defensible estimates. S ≈ an evening, M ≈ a few days, L ≈ open-ended.

Phase 1 — stop losing work

Do these before leaving the editor open on anything that matters.

Order Issue Size Why here
3 #9 — autosave overwrites external changes M The other data-loss path. Its fs.watch feed gets reused by #19.

#8 before #9. The mtime check in #9 is per-buffer state, and "buffer" is not a real concept until #8 exists.

Phase 2 — infrastructure

Neither is exciting. Both make Phase 3 substantially cheaper.

Order Issue Size Why here
4 #11 — vendor Monaco, Shiki and xterm locally M Removes the secure-context restriction that makes #12's transport awkward. Fold #14 (xterm addons) into the same PR — same script tags.
5 #24 — sidecar auth and path containment S #18 adds four write routes that all need the fixed containment check. Cheaper to fix it before there are five callers.

Phase 3 — the one that matters

Order Issue Size Why here
6 #12 — language server support L Everything above is setup for this. Split it on the way in: transport → ruby-lsp → completion/hover → diagnostics → go-to-definition. Ship one capability at a time.

Daily-driving plausibly starts here. Everything below is friction, not a blocker.

Phase 4 — cheap wins

Roughly value-per-hour. These are largely independent, so reorder by whatever is annoying you that week.

Order Issue Size Why here
7 #20 — tab close, dirty indicator, overflow S/M "I can't close this tab" lands within an hour of real use.
8 #13 — multiple terminal panels M Terminal is already self-contained; this is mostly a tab strip.
9 #16 — debounce and cancel search S Cheapest fix on the list for how much better search feels.
10 #15 — wire up project code search M The server half already exists. This is UI plus openFile(path, {line, column}).

Phase 5 — filling in

Order Issue Size Why here
11 #19 — file tree never refreshes M Reuses #9's watcher. Do it while that code is fresh.
12 #18 — create, rename, delete, move files M Feels broken without #19, hence the order.
13 #21 — git gutter, tree status, branch, blame M Highest-value item in this phase, and only this low because it is pure comfort. Pull it ahead of #18 if you find yourself missing it.

Phase 6 — polish

Order Issue Size Why here
14 #22 — command palette and keybindings M Do the command-registry refactor here, once you know which commands actually exist.
15 #23 — session persistence and settings M Late, because the set of things worth persisting is not stable until the phases above land.
16 #17 — replace the search walk with ripgrep S/M Pure performance. #16 makes the current walk tolerable; only urgent on a genuinely large repo.

Dependency graph

The edges that actually constrain the order:

#8  per-file models ──┬─→ #12 LSP (needs monaco.Uri.file models)
                      ├─→ #15 code search (reveal line survives model switch)
                      ├─→ #20 tabs (closing disposes a model)
                      └─→ #21 git (gutter decorations are per-model)

#11 vendor assets ────→ #12 LSP (page can open ws:// directly)

#9  file watching ────→ #19 tree refresh (same watcher)

#24 path containment ─→ #18 file operations (four new write routes)

#19 tree refresh ─────→ #18 file operations (ops need the tree to update)

Only Phases 1–3 have real dependencies behind them. The ordering within Phases 4–6 is soft.

Insert▾