Problem
The schema version stamped in generated specs (metadata.schema.version / schema.url) is plumbed through a fragile build-time contract:
specs-from-figma/src/Component/Metadata/constants.ts reads an esbuild --define __ANOVA_SCHEMA_VERSION__, with a hardcoded literal fallback ('0.21.0').- Every consumer's build is expected to inject that define from the resolved
@directededges/specs-schema version. SFF's own build does; the CLI inherits it via SFF's prebuilt dist; but the plugin's build-plugin.js did not — so plugin output silently fell back to the stale '0.21.0' literal (found in round 0013; patched there with a one-line define, but the underlying footgun remains).
Two recurring failure modes:
- Any bundler that includes SFF and forgets the
--define gets a silently wrong, stale version instead of a loud error.
- The fallback literal must be hand-bumped every schema release and drifts.
Proposed fix (single source of truth)
Make @directededges/specs-schema own and export its own version, and have SFF import it as a normal runtime value:
- Schema generates its version from
package.json at build (e.g. prebuild writes types/version.ts) and exports export const SCHEMA_VERSION.
- SFF
constants.ts does import { SCHEMA_VERSION } from '@directededges/specs-schema' instead of the --define + literal.
- Drop
--define:__ANOVA_SCHEMA_VERSION__ from all build scripts (SFF + plugin) and delete the hardcoded fallback.
Schema is bundled (not externalized) into both SFF and the plugin, so the value inlines correctly in every runtime (CLI, plugin sandbox) with zero per-consumer build plumbing.
Note / scope
This changes the published @directededges/specs-schema package shape (adds a public SCHEMA_VERSION export + a codegen build step) — additive/non-breaking, but a real published-package change, so it was intentionally deferred out of the 0.20.0 "Slot Content & Instance Examples" release. Schedule alongside a schema version bump.
Context: dev-testing round 0013.
Problem
The schema version stamped in generated specs (
metadata.schema.version/schema.url) is plumbed through a fragile build-time contract:specs-from-figma/src/Component/Metadata/constants.tsreads an esbuild--define__ANOVA_SCHEMA_VERSION__, with a hardcoded literal fallback ('0.21.0').@directededges/specs-schemaversion. SFF's own build does; the CLI inherits it via SFF's prebuilt dist; but the plugin'sbuild-plugin.jsdid not — so plugin output silently fell back to the stale'0.21.0'literal (found in round 0013; patched there with a one-line define, but the underlying footgun remains).Two recurring failure modes:
--definegets a silently wrong, stale version instead of a loud error.Proposed fix (single source of truth)
Make
@directededges/specs-schemaown and export its own version, and have SFF import it as a normal runtime value:package.jsonat build (e.g.prebuildwritestypes/version.ts) and exportsexport const SCHEMA_VERSION.constants.tsdoesimport { SCHEMA_VERSION } from '@directededges/specs-schema'instead of the--define+ literal.--define:__ANOVA_SCHEMA_VERSION__from all build scripts (SFF + plugin) and delete the hardcoded fallback.Schema is bundled (not externalized) into both SFF and the plugin, so the value inlines correctly in every runtime (CLI, plugin sandbox) with zero per-consumer build plumbing.
Note / scope
This changes the published
@directededges/specs-schemapackage shape (adds a publicSCHEMA_VERSIONexport + a codegen build step) — additive/non-breaking, but a real published-package change, so it was intentionally deferred out of the 0.20.0 "Slot Content & Instance Examples" release. Schedule alongside a schema version bump.Context: dev-testing round 0013.