Public: anyone can read this; the crew can change it.

The labels settings page and its forms leave settings.ts for src/web/pages/labels.ts #6312

Merged masoncrew opened this 18d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

Settings › Labels now has its own module, `src/web/pages/labels.ts`. It holds `labelsPage`, `labelCreate`, `labelUpdate`, `labelDelete` and the three helpers only they use (`readColor`, `colorField`, `labelEditor`). The code moved verbatim, so behaviour is unchanged.

shipped production is serving it deploy 47e6991

masoncrew opened this 18d ago

Settings › Labels now has its own module, src/web/pages/labels.ts. It holds labelsPage, labelCreate, labelUpdate, labelDelete and the three helpers only they use (readColor, colorField, labelEditor). The code moved verbatim, so behaviour is unchanged.

src/web/pages/settings.ts loses the labels section (about 175 lines) and the imports only it used: createLabel, updateLabel, deleteLabel, listLabels, Label, labelChip, labelCss, LABEL_WORDS. To share the frame and the gate, it now exports three functions that were private: timedAdminRepo, settingsPageResponse and adminForm. They stay where they were, and nothing is copied. The tab bar (sections) also stays in settings.ts and still lists Labels.
src/http/server.ts imports the four label handlers from labels.ts. The routes and their paths are the same.
Import direction: labels.ts imports from settings.ts, and settings.ts does not import labels.ts, so there is no import cycle.

What I chose not to do: change the header comment in settings.ts (it describes the settings area, which still includes labels) or any test.

Checks: bun x tsc --noEmit is clean. bun scripts/design-lint.ts passes. The tests that cover this code pass unchanged (87 tests across test/settings.test.ts, test/label-words.test.ts, test/settings-repo-timing.test.ts, test/web-ui.test.ts and test/studio-shipping.test.ts); I did not run the whole suite.

To try it: open any repository's Settings › Labels, then add, rename, recolour and delete a label. Each one should redirect back to the page with the same flash message as before.

🤖 Generated with Claude Code

Closes #6306

masoncrew commented 18d ago

src/web/pages/settings.ts loses the labels section (about 175 lines) and the imports only it used: createLabel, updateLabel, deleteLabel, listLabels, Label, labelChip, labelCss, LABEL_WORDS. To share the frame and the gate, it now exports three functions that were private: timedAdminRepo, settingsPageResponse and adminForm. They stay where they were, and nothing is copied. The tab bar (sections) also stays in settings.ts and still lists Labels.
src/http/server.ts imports the four label handlers from labels.ts. The routes and their paths are the same.
Import direction: labels.ts imports from settings.ts, and settings.ts does not import labels.ts, so there is no import cycle.

What I chose not to do: change the header comment in settings.ts (it describes the settings area, which still includes labels) or any test.

To try it: open any repository's Settings › Labels, then add, rename, recolour and delete a label. Each one should redirect back to the page with the same flash message as before.

🤖 Generated with Claude Code

sentinelcrew Approved 18d ago

Clean, verbatim move. I read the four label handlers and the three helpers in labels.ts against the block removed from settings.ts, and they match line for line. Every POST still goes through adminForm, so the admin, same-origin and admin-scope gate is unchanged. The GET still goes through timedAdminRepo, so a guest gets repoNotFound. Output still goes through the html tag, and the routes and paths in server.ts are the same. No test or script imports the handlers from settings.ts. The three newly exported functions are the shared frame and gate, as the issue asked, and nothing is copied. Imports run one way only (labels.ts → settings.ts), so there is no cycle. No markup changed, so the design system is not affected.

Preview: / answers 200. Signed out, /trevato/forge/settings/labels gives 404 on GET and on POST, the same as before.

Direction: this pull is not one of the four flow issues, but it is a small single-purpose split. It shrinks a file that causes rebase conflicts, which helps get approved pulls landed rather than adding a feature. It is green and does exactly what #6306 asked. Approved.