Found while implementing #7183 (PR #7291), whose first step is "build the components package".
The defect
packages/components/package.json hand-lists the packages its build needs:
"prebuild": "pnpm --filter @object-ui/types build && pnpm --filter @object-ui/core build && pnpm --filter @object-ui/react build",
"pretest": "pnpm run prebuild",
That list has drifted. @object-ui/react itself imports @object-ui/i18n and @object-ui/data-objectstack, and neither is in the chain, so on a checkout where those two have no dist the chain dies in @object-ui/react's tsc:
$ pnpm --filter @object-ui/components build # fresh worktree, nothing built yet
src/context/AppShellContext.tsx(2,41): error TS2307: Cannot find module '@object-ui/data-objectstack' or its corresponding type declarations.
src/hooks/useActionTextLocalizer.ts(58,69): error TS2307: Cannot find module '@object-ui/i18n' or its corresponding type declarations.
src/hooks/useDatasetDimensionLabels.ts(69,35): error TS2307: Cannot find module '@object-ui/i18n' or its corresponding type declarations.
src/index.ts(99,8): error TS2307: Cannot find module '@object-ui/i18n' or its corresponding type declarations.
src/utils/error-message.ts(24,40): error TS2307: Cannot find module '@object-ui/data-objectstack' or its corresponding type declarations.
ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL @object-ui/react@17.6.0 build: `tsc && node ../../scripts/check-dist-completeness.mjs`
Exit status 2
Live control, same tree, one command later: routing the identical build through turbo succeeds, because turbo derives the closure from the dependency graph rather than from a list somebody maintains by hand:
$ turbo run build --filter=@object-ui/components
Tasks: 9 successful, 9 total
The real closure turbo computes is core, data-objectstack, i18n, react, react-runtime, sdui-parser, types — seven packages; the prebuild chain names three.
Why it is worth a card rather than a shrug
The failure is invisible in the two places people usually look. CI never runs the package build directly, and any developer or agent whose tree happens to have i18n/data-objectstack already built sees it pass — so the chain reads as correct right up until someone lands in a fresh worktree, which is precisely what the repo's worktree-first rule makes the normal case for a new task. It cost this lane one full build-lock cycle, and the error it prints points at @object-ui/react's source rather than at the stale list that caused it.
It is also a class, not an isolate: a hand-maintained list of a package's own dependencies is a second, unenforced copy of package.json's dependencies, and nothing checks that the two agree. Sibling packages with the same pattern were not surveyed here.
Options (not a recommendation)
- Delete the
prebuild/pretest chain and let turbo own build ordering, which it already does correctly for every path CI takes. - Keep the chain but derive it (or gate it) so it cannot drift from the package's declared dependencies.
- Leave it and document that the package must be built through turbo.
⛔ Nothing was changed here — PR #7291 sidestepped it by going through turbo, which is option 1's behaviour without option 1's decision. Filing unassigned for triage.
Found while implementing #7183 (PR #7291), whose first step is "build the components package".
The defect
packages/components/package.jsonhand-lists the packages its build needs:That list has drifted.
@object-ui/reactitself imports@object-ui/i18nand@object-ui/data-objectstack, and neither is in the chain, so on a checkout where those two have nodistthe chain dies in@object-ui/react'stsc:Live control, same tree, one command later: routing the identical build through turbo succeeds, because turbo derives the closure from the dependency graph rather than from a list somebody maintains by hand:
The real closure turbo computes is
core,data-objectstack,i18n,react,react-runtime,sdui-parser,types— seven packages; theprebuildchain names three.Why it is worth a card rather than a shrug
The failure is invisible in the two places people usually look. CI never runs the package build directly, and any developer or agent whose tree happens to have
i18n/data-objectstackalready built sees it pass — so the chain reads as correct right up until someone lands in a fresh worktree, which is precisely what the repo's worktree-first rule makes the normal case for a new task. It cost this lane one full build-lock cycle, and the error it prints points at@object-ui/react's source rather than at the stale list that caused it.It is also a class, not an isolate: a hand-maintained list of a package's own dependencies is a second, unenforced copy of
package.json'sdependencies, and nothing checks that the two agree. Sibling packages with the same pattern were not surveyed here.Options (not a recommendation)
prebuild/pretestchain and let turbo own build ordering, which it already does correctly for every path CI takes.⛔ Nothing was changed here — PR #7291 sidestepped it by going through turbo, which is option 1's behaviour without option 1's decision. Filing unassigned for triage.