Skip to content

fix(studio): published types never name a dependency by a node_modules path - #5050

Closed
miguel-heygen wants to merge 2 commits into
mainfrom
fix/studio-cn-portable-type
Closed

miguel-heygen wants to merge 2 commits into
mainfrom
fix/studio-cn-portable-type

Conversation

@miguel-heygen

@miguel-heygen miguel-heygen commented Oct 5, 2026 •

Copy link
Copy Markdown
Collaborator

What

@hyperframes/studio's published types name cn's type through the cn package's public entry. Before, they imported it from a path inside node_modules, which does not resolve for a consumer. On some runners the type build refused to emit it at all, so Studio's build failed.

Why

cn in packages/studio/src/components/ui/cn.ts had no type annotation, so the declaration build inferred createCn's return type and named it by where it found it:

// dist/ui.d.ts on main
import * as node_modules_cn_dist_types from 'node_modules/cn/dist/types';
declare const cn: node_modules_cn_dist_types.CnFunction;

Where that path is not reachable from the package, TypeScript stops with TS2742 instead ("The inferred type of 'cn' cannot be named without a reference to '…/node_modules/cn/dist/types'"). That made Studio's build fail intermittently in the Windows render check, on a PR that does not touch Studio.

How

Two changes, each fixing its own half:

  • The Windows build failure: an explicit type. cn is annotated with CnFunction, which the cn package exports from its public entry. TypeScript no longer has to name an inferred type, so it never reaches TS2742, wherever cn is installed:
  • The broken package on Linux: no baseUrl. Studio's tsconfig set "baseUrl": ".". That is what let the declaration build write a bare node_modules/... import where it should have stopped. Its only use was the @hyperframes/player path alias, which resolves relative to the tsconfig without it. With it removed, a future export like this one still gets portable types on Linux, where the dts bundler writes the type into Studio's own declarations, and fails the build loudly where it cannot. It can no longer ship broken silently.
// dist/ui.d.ts with this change
import { CnFunction } from 'cn';
declare const cn: CnFunction;

No visible change

Types and build config only. The value and the runtime bundle are unchanged.

Test plan

  • Before. Built packages/studio on main: dist/ui.d.ts imports from 'node_modules/cn/dist/types'.
  • After. The same build with this change: dist/ui.d.ts imports CnFunction from 'cn', and the build passes.
  • Without baseUrl, unannotated. Main's cn.ts with baseUrl removed builds on Linux, and dist/ui.d.ts declares CnFunction itself with no node_modules import. Where cn resolves only from the repo root, as on the Windows runner, that same build still fails with TS2742, which is why the annotation is needed too.
  • Nothing else moves. With the annotation, the declaration output is byte-identical with and without baseUrl, and Studio's typecheck passes.

@github-actions

github-actions Bot commented Oct 5, 2026 •

Copy link
Copy Markdown

Edit accuracy: accurate 2040 (base branch 2040), smooth 1701 of those

The gate passes.
Smoothness is reported in the artifact, not gated. A case fails only if it fails 2 of 3 runs.

Quarantined, measured but not gated (0)

@miguel-heygen miguel-heygen changed the title fix(studio): published types name cn by its package, not a node_modules path fix(studio): published types never name a dependency by a node_modules path Oct 5, 2026
@miguel-heygen

Copy link
Copy Markdown
Collaborator Author

Folded into #5048 (same two commits), so it lands with that PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant