Two of the hand-written unions in packages/core/types/index.d.ts no longer match the arrays they describe.
GeoId (types/index.d.ts:17) has six members; GEO_IDS (palette.js:113) ships seven — cloud arrived with #6 and the union did not move with it.
GridId (types/index.d.ts:19) has three; GRID_IDS (palette.js:84) ships six, so ruled, crosses and iso cannot be named from TypeScript at all.
So setGeoKind('cloud') and setGrid('iso') are both type errors against shipped behaviour.
npm run typecheck cannot catch this, which is why it happened twice. The declaration says export const GRID_IDS: GridId[] (types/index.d.ts:101), so TypeScript takes the union as the truth about the array and never reads palette.js. CONTRIBUTING asks for declarations to move with the API; there is nothing behind that rule, and the two drifted independently five days apart.
packages/core/README.md lags the same way, plus a wrong default:
grid: 'lines', // 'none' (default) | 'lines' | 'dots' :27
board.editor.setGrid('dots') // 'none' | 'lines' | 'dots' :52
'lines' is the default, not 'none' — editor.js:35, and the fallback at :39 agrees.
What it takes
cloud into GeoId; ruled, crosses and iso into GridId- README
:27 and :52 to list all six, and to mark 'lines' as the default
- A test in
packages/core/test/ that reads types/index.d.ts as text and compares each *_IDS export against its union — text, because the unions do not exist at runtime. Around 30 lines, no new dependency, and it fails on the next shape someone adds rather than on the release after.
Happy to send this as a PR. If you would rather not carry the test, say so and I will send just the declaration and README fix.
Two of the hand-written unions in
packages/core/types/index.d.tsno longer match the arrays they describe.GeoId(types/index.d.ts:17) has six members;GEO_IDS(palette.js:113) ships seven —cloudarrived with #6 and the union did not move with it.GridId(types/index.d.ts:19) has three;GRID_IDS(palette.js:84) ships six, soruled,crossesandisocannot be named from TypeScript at all.So
setGeoKind('cloud')andsetGrid('iso')are both type errors against shipped behaviour.npm run typecheckcannot catch this, which is why it happened twice. The declaration saysexport const GRID_IDS: GridId[](types/index.d.ts:101), so TypeScript takes the union as the truth about the array and never readspalette.js. CONTRIBUTING asks for declarations to move with the API; there is nothing behind that rule, and the two drifted independently five days apart.packages/core/README.mdlags the same way, plus a wrong default:'lines'is the default, not'none'—editor.js:35, and the fallback at:39agrees.What it takes
cloudintoGeoId;ruled,crossesandisointoGridId:27and:52to list all six, and to mark'lines'as the defaultpackages/core/test/that readstypes/index.d.tsas text and compares each*_IDSexport against its union — text, because the unions do not exist at runtime. Around 30 lines, no new dependency, and it fails on the next shape someone adds rather than on the release after.Happy to send this as a PR. If you would rather not carry the test, say so and I will send just the declaration and README fix.