global virtual store: bit build's env type-checks fail locally — published .d.ts can't reach @types/core-aspects from store slots

Summary

With enableGlobalVirtualStore (teambit/bit#10582), bit install/bit status/bit compile work in the workspace, but bit build of components whose env type-checks against published packages fails locally with dozens of degraded-type errors (Property 'className' does not exist on type 'LoaderRibbonProps', conflicting typescript instances, etc.).

Mechanism

A published package's .d.ts reaches undeclared packages (@types/react, core @teambit/* aspects) by walking up out of node_modules/.pnpm into the workspace — accidental, but universal under the project-local layout. From a global-store slot there is nothing to walk up into, and TypeScript consults neither NODE_PATH nor the ESM loader, so the types silently collapse.

The repo's own tsc --noEmit gate was fixed in #10582 with root-tsconfig.json paths:

"paths": {
  "react": ["./node_modules/@types/react"],
  "react-dom": ["./node_modules/@types/react-dom"],
  "@teambit/*": ["./node_modules/@teambit/*"]
}

but env-driven build tsconfigs (react env's TSCompiler, compiler:declaration, etc.) don't extend the root tsconfig, so build-time type-checks under the global virtual store still hit the degradation. CI is unaffected (non-GVS); this bites local bit build/bit tag in a GVS workspace.

Suggested direction

When the workspace runs under the global virtual store, bit could inject the equivalent paths (workspace-node_modules-anchored) into the tsconfigs it materializes for env compilation — the type-layer counterpart of the runtime NODE_PATH bridge, applied at the same seam where env tsconfigs are written/merged. Alternatively (longer-term), the affected published packages declare their type deps (@types/react as a peer/dep), which fixes it at the source, as packageExtensions already does for the tsconfig-extends class.

Generated with Claude Code