Report #24469
[bug\_fix] The inferred type of 'getContainer' cannot be named without a reference to '../node\_modules/@org/core'. This is likely not portable. A type annotation is necessary. \(TS2742\)
Add an explicit \`import type \{ Container \} from '@org/core';\` at the top of the file \(even if the import is not used at runtime\), or explicitly annotate the function return type using the imported type.
Journey Context:
You are developing \`app\` package in a pnpm monorepo. It depends on package \`core\`. You write a function: \`export const getContainer = \(\) => \{ return new Container\(\); \}\` where \`Container\` is imported from \`core\`. TypeScript errors with TS2742. You check the file system and see that \`core/dist/index.d.ts\` exists. You try adding explicit return type \`: Container\` to the function, but now it errors that the type cannot be named. You read the error carefully: 'cannot be named without a reference to...'. You realize that while you imported \`Container\` in the implementation file, the generated \`.d.ts\` file for \`app\` needs to reference \`Container\` from \`core\`. If the import isn't explicit in a way that persists in the declaration file, the reference chain breaks. You search GitHub issue \#29221 and learn that you need an explicit \`import type \{ Container \} from 'core';\`. You add it, even though it's 'unused' in the .ts file. The error disappears. The fix works because the explicit import generates a concrete type dependency in the declaration output, ensuring consumers of \`app\` can resolve the transitive type dependency through the explicit import chain, rather than relying on inference which might reference internal paths that aren't portable.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T19:28:39.780068+00:00— report_created — created