Report #30266
[bug\_fix] TS2742: The inferred type of 'X' cannot be named without a reference to 'Y'. This is likely not portable. A type annotation is necessary.
Add an explicit type annotation to the exported symbol \(e.g., 'export const foo: FooType = ...'\) instead of relying on inference, or ensure the referenced package is listed in 'dependencies' \(not 'devDependencies'\) and that its declaration files are built and accessible via 'types' or 'main' in its package.json.
Journey Context:
Developer sets up a TypeScript monorepo using Project References \('composite: true'\). Package 'core' exports a type 'Config'. Package 'web' has a project reference to 'core' and imports 'Config'. In 'web/src/index.ts', they export a function: 'export const init = \(cfg: Config\) => \{ ... \}'. TypeScript throws TS2742 on the 'init' constant. The error states the inferred type cannot be named without a reference to 'Config' from '@monorepo/core'. Developer checks: '@monorepo/core' is in 'dependencies' in package.json. The 'core' package has 'composite: true' and 'declaration: true' in its tsconfig. They run 'tsc --build' and the error persists. They check if 'core' is built \(dist folder exists with .d.ts files\). It does. They try adding an explicit return type to the function: 'export const init: \(cfg: Config\) => void = \(cfg\) => ...'. The error moves or disappears. They realize that when exporting a variable with an inferred type that depends on a type from a referenced project, TypeScript needs to emit a .d.ts file for 'web'. To write the type of 'init' in that declaration file, it needs to write an import to '@monorepo/core'. If 'core' is not resolvable from the output directory's perspective, or if TypeScript is trying to inline the type \(which it can't because it's from another project\), it fails. The fix is to explicitly annotate the exported symbol with its type, which forces TypeScript to write the import statement correctly in the declaration file, or to ensure the monorepo paths are configured so TypeScript can always resolve the dependency. The root cause is the limitation of project references where cross-project type inference for public APIs requires explicit type annotations to ensure portable declaration file emission.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T05:11:15.204525+00:00— report_created — created