refactor(keycodes): Consolidate ZMK names and picker labels into one TS table#10
Merged
Conversation
Lock in the current behaviour of the picker label pipeline (hid_usage_get_metadata / hid_usage_get_label) and the keymap-parser canonical table before consolidating them into a single source of truth. Any drift introduced by the upcoming SSOT refactor will trip the snapshots loudly. - Add Vitest as a devDependency with `npm test` / `npm run test:watch`. - src/hid-usages.test.ts snapshots every (page, usage) pair that surfaces a label today, plus the page list. - src/keymap-parser.test.ts snapshots the full canonical name table and asserts forward/reverse name<->code round-trip plus modifier wrapper round-trip. Co-Authored-By: Claude <noreply@anthropic.com>
…TS table ZMK keymap text names (used by import / export) and picker UI labels (used by the keycap grid) used to live in two independent places — an inline `ZMK_KEYCODES` array inside keymap-parser.ts and the hid-usage-metadata.json from upstream PR zmkfirmware#159. Both could drift; HID 7:230 famously labelled "AltGr" in the picker but exported as `&kp RALT`. Promote both to a single TS table in src/keycodes.ts: - One `Keycode` row per (page, usage) carries the ZMK `name`, picker `short` / `med` / `long`, and picker `category`. Editing one row updates both the picker and the exporter. - keymap-parser.ts derives `keycodeLookup` / `codeToZmkName` from the rows whose `name` is set; the parser-side alias map widens to also accept any `short` / `med` / `long` label as a parser input, so hand-edited keymaps using picker labels (e.g. "Volume Up") still resolve. - hid-usages.ts looks up labels from the same table, falling back to the HID spec name for usages we don't curate. - hid-usage-metadata.json is removed. The Vitest snapshot baselines from the previous commit catch any visual regression — picker labels and the canonical name table are byte-for-byte identical post-refactor. Closes #2. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves the triple-defined key naming problem tracked in #2: ZMK keymap names and picker UI labels used to live in two independent files (an inline
ZMK_KEYCODESarray inkeymap-parser.tsandhid-usage-metadata.jsonfrom upstream PR zmkfirmware#159), and could drift — HID 7:230 was famously labelledAltGrin the picker but exported as&kp RALT.This PR promotes both into a single TypeScript table in
src/keycodes.ts, so editing one row updates both the picker label and the export name.src/keycodes.ts(oneKeycoderow per(page, usage), carryingname+short/med/long+category).keymap-parser.tsderives lookups from rows withname; parser also accepts any curatedshort/med/longas an alias (so hand-edited files using picker labels still resolve).hid-usages.tslooks up labels from the same table; HID spec table remains as the fallback for usages we don't curate.hid-usage-metadata.jsonremoved.npm test) that lock in the pre-refactor behaviour. Snapshots are byte-for-byte identical post-refactor — proof there's no visual regression.Closes #2.
Test plan
npx vitest run— 7/7 pass.npx tsc -p .— clean.npx vite build— clean.🤖 Generated with Claude Code