Prior search
What's the problem
Scripts defined in paseo.json show up alphabetically in the Scripts dropdown, not in the order I wrote them in the file. I group related scripts on purpose (e.g. dev, dev:api, dev:web, then build, then deploy), but they get re-sorted, so my most-used script isn't first and related ones get split apart. The only way to influence order today is to rename scripts into an alphabetical sequence (1-dev, 2-build, …), which is ugly and leaks ordering into names that are shown in the UI.
What would solve it
Phase 1 (small): respect file order. The pipeline already preserves paseo.json key order from disk all the way to the wire — the only thing that discards it is one alphabetical sort right before scripts are emitted (packages/server/src/server/script-status-projection.ts:259, sortPayloads). Replacing that with file order makes the dropdown reflect what I wrote.
Because scripts is a JSON object and string-key insertion order survives the full round-trip — read → JSON.parse → Zod z.record → JSON.stringify write (already covered by the round-trip test in paseo-config-file.test.ts) — no schema or protocol change is needed; order is simply respected instead of thrown away. Two small notes: running-but-unconfigured ("orphan") scripts would append after configured ones (could stay alphabetical among themselves), and pure-integer script names would still reorder due to JS object semantics — a non-issue for real names.
Phase 2 (optional follow-up): drag-to-reorder in Project Settings. If hand-editing the file isn't enough, the Scripts section of Project Settings already does add/edit/remove, there's already a write path (WriteProjectConfig RPC + atomic writePaseoConfigForEdit), and there's already a drag primitive (sortable-inline-list.web.tsx, @dnd-kit, with a native fallback). Reordering = rebuild the scripts object's keys in the new order and save through the existing RPC; the file rewrite preserves order and the dropdown follows. Still no schema change. This mirrors the "custom order + reasonable fallback sort" shape from #1524, with the fallback being Phase 1's file order.
I'd ship Phase 1 on its own first (essentially a one-function change) and only do Phase 2 if you agree with this change.
Alternatives you considered
- Keep alphabetical, rename scripts to force order (
1-dev, 2-build) — works today but pollutes names that are shown in the UI.
- Client-side custom order persisted per-device (like tab order) — rejected: invisible to
paseo.json, doesn't travel with the repo or to other devices; the file is the natural source of truth.
- Change
scripts to an array in the schema to make order explicit — rejected as unnecessary and back-compat-breaking: object key order already round-trips faithfully, so the hash is sufficient.
Prior search
What's the problem
Scripts defined in
paseo.jsonshow up alphabetically in the Scripts dropdown, not in the order I wrote them in the file. I group related scripts on purpose (e.g.dev,dev:api,dev:web, thenbuild, thendeploy), but they get re-sorted, so my most-used script isn't first and related ones get split apart. The only way to influence order today is to rename scripts into an alphabetical sequence (1-dev,2-build, …), which is ugly and leaks ordering into names that are shown in the UI.What would solve it
Phase 1 (small): respect file order. The pipeline already preserves
paseo.jsonkey order from disk all the way to the wire — the only thing that discards it is one alphabetical sort right before scripts are emitted (packages/server/src/server/script-status-projection.ts:259,sortPayloads). Replacing that with file order makes the dropdown reflect what I wrote.Because
scriptsis a JSON object and string-key insertion order survives the full round-trip — read →JSON.parse→ Zodz.record→JSON.stringifywrite (already covered by the round-trip test inpaseo-config-file.test.ts) — no schema or protocol change is needed; order is simply respected instead of thrown away. Two small notes: running-but-unconfigured ("orphan") scripts would append after configured ones (could stay alphabetical among themselves), and pure-integer script names would still reorder due to JS object semantics — a non-issue for real names.Phase 2 (optional follow-up): drag-to-reorder in Project Settings. If hand-editing the file isn't enough, the Scripts section of Project Settings already does add/edit/remove, there's already a write path (
WriteProjectConfigRPC + atomicwritePaseoConfigForEdit), and there's already a drag primitive (sortable-inline-list.web.tsx, @dnd-kit, with a native fallback). Reordering = rebuild thescriptsobject's keys in the new order and save through the existing RPC; the file rewrite preserves order and the dropdown follows. Still no schema change. This mirrors the "custom order + reasonable fallback sort" shape from #1524, with the fallback being Phase 1's file order.I'd ship Phase 1 on its own first (essentially a one-function change) and only do Phase 2 if you agree with this change.
Alternatives you considered
1-dev,2-build) — works today but pollutes names that are shown in the UI.paseo.json, doesn't travel with the repo or to other devices; the file is the natural source of truth.scriptsto an array in the schema to make order explicit — rejected as unnecessary and back-compat-breaking: object key order already round-trips faithfully, so the hash is sufficient.