How should croct.json5 version specifiers and slots.d.ts play with CI builds?
Setting up CI for a Next.js project and I want the Croct typing story fully deterministic. Three questions:
- How exactly do version specifiers in croct.json5 work? I see a plain "3" in ours and I want to know what other forms are legal (at least json5 lets me leave trailing commas, small mercies).
- Should slots.d.ts be committed, or generated fresh in CI?
- Our first CI run failed with TS2304: Cannot find name 'SlotContent' which suggests the generated types never existed in the runner.
What is the intended workflow here?
1 answer
The intended workflow is simpler than it looks.
Version specifiers in croct.json5 accept three forms: an exact version like "3", a range like "1 - 3", or a set like "1, 4, 5". They pin which slot and component versions your code is written against, and npx croct upgrade bumps them and regenerates the types in one step.
Commit slots.d.ts to the repo. Generating it at build time requires an API fetch, which makes CI network-dependent and nondeterministic, exactly what you are trying to avoid. With the file committed, CI type-checks against the same types every developer saw locally. That also explains your TS2304: the runner had no generated file, so SlotContent<'home-hero@1'> had nothing to resolve against.
Locally, npx croct install registers a postinstall hook that keeps the types in sync after dependency installs, so the committed file stays fresh without anyone thinking about it. See Keeping your project in sync for when and how to synchronize types.
Committed the file, CI is green and deterministic. The postinstall hook was the missing piece, thanks.