You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(codegen-ts): an inline field.enum gets a runtime constant, not just a type
The generated entity file tells its reader to "use these instead of magic strings", and for
the one field kind where a typo is most likely it did not give them anything to use. A type
alias is erased at runtime, so code needing a MEMBER had nothing to import — while the same
member list appeared three or four more times in that same file (the Drizzle `enum:` option,
the type union, each Zod schema). A package-level SHARED enum has always had a runtime
constant; an inline one had none anywhere.
An inline enum now emits `export const <Owner><Field>Enum = z.enum([...])` beside its alias,
under the shared naming convention, so which kind of enum it is stops mattering at the call
site. An entity file also re-exports a MATERIALIZED shared enum's constant beside its type.
It deliberately does NOT for a `@provided` enum. That declaration lives in a module the
ADOPTER owns and configured, and nothing here knows or can require that it exports a Zod
constant — naming one emits an import of a symbol that may not exist and breaks their build.
Only the type is contracted for a provided enum. The FR-019 conformance test caught the first
attempt, which is the second time this release that the provided/materialized distinction has
been the thing a change got wrong.
Found on the public reference app running the 1.0 candidate, where the same status symbols
appear as literals in five hand-written files. Gated on the declared case, the
inherited-through-extends case, and one-const-per-alias.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01At3v6M6uqECZ2Sb5eUv6YY
0 commit comments