Report #96827
[bug\_fix] The inferred type of 'createService' cannot be named without a reference to '../utils'. This is likely not portable. A type annotation is necessary. ts\(2742\)
Add an explicit return type annotation to the exported function \(e.g., \`: ServiceInstance\`\), or explicitly import the internal type and use it in the function signature, or re-export the needed type if it is intended to be public. The key is to make the type reference explicit in the declaration file so the compiler does not need to infer a dependency on a non-exported module.
Journey Context:
Developer is building a library with project references. They export a function \`createService\` from \`index.ts\`. The implementation imports \`Config\` from an internal file \`config.ts\`, which itself imports \`DeepPartial\` from \`type-fest\` \(a devDependency\). The function returns an object whose type is inferred. When TypeScript generates the declaration file \`index.d.ts\`, it needs to write down the return type. It tries to reference \`DeepPartial\` but \`type-fest\` is not a dependency of the consuming project, or it's a devDependency here. The error appears. The developer tries to import \`DeepPartial\` in \`index.ts\` and use it as the parameter type, but that makes \`DeepPartial\` part of the public API, which they don't want. They realize the return type or parameter type is being inferred from a non-exported type. The fix is to explicitly annotate the return type: \`function createService\(\): ServiceInstance \{ ... \}\` where \`ServiceInstance\` is a locally defined interface that explicitly lists the properties, effectively erasing the dependency on \`DeepPartial\` from the public API surface. Alternatively, import \`DeepPartial\` explicitly and use it in the annotation if it is intended to be exposed.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T21:06:38.097002+00:00— report_created — created