Repository navigation
app-shell tsc build fails under full turbo build (missing plugin-* .d.ts), masked by turbo cache #1760
Description
Problem
@object-ui/app-shell builds with tsc (composite). Under a full turbo build (pnpm turbo run build --filter='./packages/*', as the performance-budget.yml "Bundle Analysis" job runs), app-shell's tsc fails with ~25 error TS2307: Cannot find module '@object-ui/plugin-*' across many files (DashboardView, ReportView, RecordDetailView, ObjectView, previews, …) plus cascading IntrinsicAttributes / implicit-any errors that are all downstream of the unresolved plugin modules.
This is long-masked by turbo cache: any PR that does not change an app-shell dependency gets a cache hit for app-shell#build and the job is green (e.g. #1743). The first PR that touches an app-shell dependency (e.g. #1757 changed @object-ui/types + plugin-charts/list/view) invalidates the cache, app-shell actually re-builds, and the latent failure surfaces.
Evidence
pnpm --filter @object-ui/app-shell buildin isolation (deps'distalready present) → exit 0, 0 errors.pnpm turbo run build --filter='./packages/*'from clean → app-shell fails (37 successful, 1 failed). Same in CI Bundle Analysis (re-run reproduced).- All errors are module-resolution for plugin-* packages app-shell does declare as deps; none are in PR-specific code.
Likely root cause
plugin-* packages build via vite build; app-shell's tsc needs their .d.ts. Under turbo's parallel build the .d.ts for some plugin-* packages isn't reliably present/ready when app-shell's tsc runs (vite dts emit timing / declaration outputs not declared as turbo outputs for cache-correct ordering). app-shell's tsconfig references only 6 composite packages; the plugin-* deps resolve via node module resolution against dist.
Suggested directions (pick one)
- Ensure every plugin-*
vite buildemits.d.tsand declares it in turbooutputsso ordering/caching is correct. - Switch app-shell's build off composite
tscto the samevite buildthe plugin packages use. - Add the plugin-* packages to app-shell
tsconfig.references(requires they be composite).
Impact
Blocks the "all-green" bar for any PR that changes an app-shell dependency, even when the PR's own code is correct (e.g. #1757, verified via Build & E2E + in-browser). Surfaced by objectstack-ai/objectstack#1890 / #1757.
Activity
os-zhuang commentedon Jun 15, 2026
Diagnosis (upgraded from "likely" to confirmed direction)
Confirmed structural anomaly. plugin-* packages generate
.d.tsviavite-plugin-dts ^5configured withcompilerOptions: { rootDir: resolve(__dirname, '../..') }(the monorepo root) +resolve.aliasmapping@object-ui/*to each package'ssrc+skipDiagnostics: true. Result: a deeply nested dist layout —i.e. every plugin's dts emit walks cross-package
srctype graphs (via the aliases) and writes a root-anchored nested tree.Confirmed flaky (not a stable config error). #1764 changed an app-shell dependency → app-shell must rebuild (cache miss) → yet it went green; #1757 (same app-shell code) went red. So a rebuild of app-shell succeeds sometimes and fails others → a concurrency race, masked the rest of the time by turbo cache.
Root cause (high confidence). Under a full parallel
turbo run build,vite-plugin-dtsgenerating the nested + cross-package-src.d.tsfor ~15 plugins concurrently is unstable (cross-package src analysis load + race / late flush), so app-shell's compositetscintermittently can't resolve some plugin's.d.ts(Cannot find module '@object-ui/plugin-*'). Runningapp-shell buildin isolation (deps' dist already present) always succeeds — consistent with the race.Fix options (need verification with repeated full builds)
rootDirto each package'ssrcso emit is flat (dist/*.d.ts, no nestedpackages/.../srctree) and stops re-walking cross-package src — likely the smallest, highest-leverage change (apply across plugins).vite-plugin-dtswith a dedicatedtsc --emitDeclarationOnlystep (deterministic, turbo-trackable) for the declaration output.tsctovite build(its own dts), removing the composite cross-package resolution requirement.Why not landed in this pass
This is a flaky build-system fix: it needs a reliable turbo environment + several clean full builds to confirm the race is gone (a half-verified "fix" risks looking green while still flaky). My investigation worktree couldn't install turbo's platform binary reliably (
Turborepo failed to start), and verifying flakiness needs repeated slow builds. Best done as a focused pass. Diagnosis + fix options recorded here.fix(build): deterministic flat plugin .d.ts with bare cross-package s…
fix(build): cache composite tsc .tsbuildinfo as a turbo output (#1767)