# How should croct.json5 version specifiers and slots.d.ts play with CI builds?

Asked by fbraun on 2026-06-30. Tags: cli, typescript, workflow.

Setting up CI for a Next.js project and I want the Croct typing story fully
deterministic. Three questions:

1. 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).
2. Should slots.d.ts be committed, or generated fresh in CI?
3. 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

### Accepted answer from Marcos Passos (2026-06-30)

The intended workflow is simpler than it looks.

Version specifiers in [croct.json5](https://docs.croct.com/reference/cli/configuration) 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](https://docs.croct.com/immersion/guides/keeping-project-in-sync)
for when and how to synchronize types.

#### Reply from fbraun (2026-07-01)

Committed the file, CI is green and deterministic. The postinstall hook
was the missing piece, thanks.