Report #36177
[bug\_fix] Default export of the module has or is using private name 'X'. ts\(4082\)
Export the referenced type explicitly using \`export type \{ X \}\` or \`export interface X\`, or restructure the code to avoid exposing the internal type in the public API signature. Root cause: When generating declaration files \(.d.ts\) with declaration: true, TypeScript cannot reference a type that isn't exported because external consumers would have no way to name that type in their own code, breaking the type system's name resolution.
Journey Context:
Developer creates an internal interface \`Config\` used only for typing a class constructor, but doesn't export it from the module since it's an implementation detail. They export the class as default: \`export default class Service \{ constructor\(config: Config\) \{\} \}\`. When running \`tsc\` with \`declaration: true\` to generate .d.ts files, TypeScript errors with "Default export has or is using private name 'Config'". The developer initially tries to inline the type in the constructor, but it's too complex with nested objects. They realize that because the Config type appears in the public API \(the constructor signature\), it becomes part of the module's external type signature. For consumers to type-check against this class, they need to be able to reference the Config type. The developer adds \`export type \{ Config \}\` \(or \`export interface Config\`\), and the declaration file now correctly exports both the Service class and the Config type it depends on.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T15:12:14.815289+00:00— report_created — created