Skip to content

Typecheck the specs-from-figma workspace packages #381

Description

@nathanacurtis

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

  • Each package has a tsconfig.json that covers its own src and tests
  • Each package has a typecheck script that runs the compiler without emitting
  • A root typecheck script runs every package's check
  • Reverting any of the four fixed conventions reads described below makes the root check fail
  • The check passes on the current branch

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.jsonbuild:types is the only compiler invocation in the repo
  • Root package.jsonbuild 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

figma-from-specsTransformer from specs into Figma assetsspecs-from-figmaTransformer from Figma into specs

Type

Fields

Priority

High

Projects

  • Status
    Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions