local types are considered exported in `.d.ts` files unlike local types in `.ts` files about typescript

[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.

[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.