Problem
Most of the packages in the specs-from-figma repo are never typechecked, so a type error can ship and stay shipped. Nothing in the repo fails when the compiler would.
The bundler is the only thing that reads the source, and esbuild strips types without checking them. Tests do not typecheck either. The result is that a schema change can leave a package reading a shape that no longer exists, and every signal stays green.
This is long-standing — it predates the current release branch, and figma-from-specs has never had a tsconfig.json in any branch's history.
Solution
Every package in the workspace is typechecked by a command, and one root command checks them all. A shape mismatch against @directededges/specs-schema fails that command instead of surfacing later as missing output.
Acceptance criteria
Problems
figma-from-specs has no tsconfig.json at all, so it cannot be checked even on demand
react-from-specs and webcomponents-from-specs have a tsconfig.json, but no script invokes the compiler
specs-from-figma is checked only incidentally, as a side effect of emitting declarations during build:types
- The repo has no CI workflows, so nothing runs even the checks that do exist
- Test fixtures drift alongside the code they exercise, so a suite can stay green while the shape it asserts is already gone
Workspace
Found while migrating the Figma plugin to the platform-keyed conventions shape introduced by ADR-073. Building the plugin against the engine source surfaced the errors, because the plugin is the only consumer whose compiler ever reads these files.
Concretely: four sites in figma-from-specs were still reading the pre-ADR-073 conventions.figma path. They resolve to undefined rather than throwing, so rendering silently lost key reversal, skipped the code-only props container, and saw no image source props. The test fixtures carried the same outdated shape, so the suite agreed with the stale code and passed. The only way this surfaced was running the compiler from outside the repo and filtering out unrelated rootDir noise.
Impacted code
packages/figma-from-specs/ — no tsconfig.json; the four stale reads lived in src/Keys/KeyReversal.ts and src/Props/CodeOnlyProps.ts
packages/react-from-specs/tsconfig.json and packages/webcomponents-from-specs/tsconfig.json — present, unused by any script
packages/specs-from-figma/package.json — build:types is the only compiler invocation in the repo
- Root
package.json — build and build:types target specs-from-figma only
Notes
The four stale reads themselves are already fixed on feat/primitive-composition. This issue is about the gap that let them exist and stay invisible, not about those specific sites.
Adding the compiler to these packages will likely surface a backlog of pre-existing errors. Worth a first pass to see the size before deciding whether to fix them all or start with a narrower tsconfig and tighten it.
Implementation details are tracked internally.
Problem
Most of the packages in the
specs-from-figmarepo are never typechecked, so a type error can ship and stay shipped. Nothing in the repo fails when the compiler would.The bundler is the only thing that reads the source, and
esbuildstrips types without checking them. Tests do not typecheck either. The result is that a schema change can leave a package reading a shape that no longer exists, and every signal stays green.This is long-standing — it predates the current release branch, and
figma-from-specshas never had atsconfig.jsonin any branch's history.Solution
Every package in the workspace is typechecked by a command, and one root command checks them all. A shape mismatch against
@directededges/specs-schemafails that command instead of surfacing later as missing output.Acceptance criteria
tsconfig.jsonthat covers its ownsrcandteststypecheckscript that runs the compiler without emittingtypecheckscript runs every package's checkconventionsreads described below makes the root check failProblems
figma-from-specshas notsconfig.jsonat all, so it cannot be checked even on demandreact-from-specsandwebcomponents-from-specshave atsconfig.json, but no script invokes the compilerspecs-from-figmais checked only incidentally, as a side effect of emitting declarations duringbuild:typesWorkspace
Found while migrating the Figma plugin to the platform-keyed conventions shape introduced by ADR-073. Building the plugin against the engine source surfaced the errors, because the plugin is the only consumer whose compiler ever reads these files.
Concretely: four sites in
figma-from-specswere still reading the pre-ADR-073conventions.figmapath. They resolve toundefinedrather than throwing, so rendering silently lost key reversal, skipped the code-only props container, and saw no image source props. The test fixtures carried the same outdated shape, so the suite agreed with the stale code and passed. The only way this surfaced was running the compiler from outside the repo and filtering out unrelatedrootDirnoise.Impacted code
packages/figma-from-specs/— notsconfig.json; the four stale reads lived insrc/Keys/KeyReversal.tsandsrc/Props/CodeOnlyProps.tspackages/react-from-specs/tsconfig.jsonandpackages/webcomponents-from-specs/tsconfig.json— present, unused by any scriptpackages/specs-from-figma/package.json—build:typesis the only compiler invocation in the repopackage.json—buildandbuild:typestargetspecs-from-figmaonlyNotes
The four stale reads themselves are already fixed on
feat/primitive-composition. This issue is about the gap that let them exist and stay invisible, not about those specific sites.Adding the compiler to these packages will likely surface a backlog of pre-existing errors. Worth a first pass to see the size before deciding whether to fix them all or start with a narrower
tsconfigand tighten it.