local types are considered exported in .d.ts files unlike local types in .ts files

[eps1lon]

🔎 Search Terms

ts2460 export type

🕗 Version & Regression Information

• This is the behavior in every version I tried (down to 2.0), and I reviewed the FAQ for entries about ?

⏯ Playground Link

No response

💻 Code

Full repro: https://github.com/eps1lon/ts-module-auto-export

index.tsx

import type { Private as DeclarationPrivate } from "./declaration";
import type { Private as LibraryPrivate } from "./library";

export const foo: DeclarationPrivate = { foo: "bar" };
export const bar: LibraryPrivate = { foo: "bar" };

declaration.d.ts

/**
 * @internal
 */
type Private = {
  foo: string
}

export type Public = Private | null

library.ts

/**
 * @internal
 */
type Private = {
  foo: string
}

export type Public = Private | null

🙁 Actual behavior

Import of local types is allowed in .d.ts files. Only Module '"./library"' declares 'Private' locally, but it is not exported.ts(2459) is raised

🙂 Expected behavior

Local types are not exposed from .d.ts files unless they have an export modifier. We should get Module '"./declaration"' declares 'Private' locally, but it is not exported.ts(2459) as well.

The other issue is that TypeScript removes the local types from the declaration for library.ts instead of keeping it as a local type.

This is a problem for libraries since every type is automatically part of the public API and we can't easily remove implementation details.

If TypeScript would hide local types, it would also need to make sure that emitted declarations don't reference those types.

The real-world issue is with React types. If TypeScript has to infer the type it may decide to either reference React.ReactNode explicitly (good) or inline all its members (bad) e.g.

class Component extends React.Component<{ children?: React.ReactNode }> {
  render() {
    if (Math.random()) {
      return <div />
    }
    return this.props.children
  }
}

will be emitted as

export declare class Component extends React.Component<{ children?: React.ReactNode }> {
    render(): string | number | boolean | Iterable<React.ReactNode> | import("react/jsx-runtime").JSX.Element | null | undefined;
}

Additional information about the issue

Original issue: vercel/next.js#63185

Maybe related to

• Declaration emit reveals paths within dependency that were not referred to in the source file #38111

[RyanCavanaugh]

This is the intended behavior unless you have an export { }; in the file (which tsc automatically inserts)

[fatcerberus]

declaration.d.ts already has an export though?

[eps1lon]

This is the intended behavior unless you have an export { }; in the file (which tsc automatically inserts)

This doesn't work in module augmentation.

// react.d.ts
export = React;
export as namespace React;
export {}

declare namespace React { }
// augmentation.d.t.s
export {}

declare module '.' {
   // can't put `export {}` here
   interface Whatever {}
}

will cause emissions of React.Whatever

Also:
it is intended behavior that it removes local types? What other bug would including local types cause?

[RyanCavanaugh]

This doesn't work in module augmentation.

In module augmentation, you can already refer to types in the outer block

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[eps1lon]

In module augmentation, you can already refer to types in the outer block

@RyanCavanaugh I don't understand what to make of this statement? I understand, that I can do that. How is that relevant here?

Edit:

You mean I should move it outside the module augmentation block and then it becomes hidden? Do we have lint rules for that in DT?

[RyanCavanaugh]

You mean I should move it outside the module augmentation block and then it becomes hidden?

Correct

Do we have lint rules for that in DT?

I'm not sure how/why we would? Both locations are valid depending on intent.

[jakebailey]

If you mean to flag unused ones that aren't exposed, those will get flagged once I have time to work on typescript-eslint/typescript-eslint#8611 and add it to DT (once I reimplement these scoping rules there), but yeah, there's no way to say "are you sure you meant to export that".

[eps1lon]

but yeah, there's no way to say "are you sure you meant to export that".

I'm pretty sure if you write type A = number; export type B = string; you either didn't meant to export A, or we can just force you to write export type A = number which is what we (used to?) do in DT packages where you either have to write export type ... everywhere or place an explicit export {}.

Why we need treat .d.ts, .ts and declare module entirely separately, I do not understand. I'd get it if this is just a just-so thing for backwards compat. But you're currently arguing for this like you would do it again if you could start from scratch and that I'm just not seeing.

[RyanCavanaugh]

Unless explicitly asked, I'm not here to discuss what we'd do differently from a blank slate perspective. Those responses are too long to fit in these tiny textboxes.

[jakebailey]

But you're currently arguing for this like you would do it again if you could start from scratch and that I'm just not seeing.

"Intended" can mean "this sucks but we can't change it and we are intentionally not changing it".

But on DT, we can certainly try and create a lint rule that complains about mixed-exported types in modules without export {} (or force export {} in all files containing exports), or something, if that's the concern.