Fix redundant export {} in declaration file

[Dunqing]

Fixes #51338

[Dunqing]

@Dunqing please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree

[weswigham]

This is not sufficient to fix the issue. I'm not sure @RyanCavanaugh remembered in the linked issue, but we emit a export {} not just to ensure module-ness, but to actually make privately scoped names work at all - unless a declaration file has a export declaration (not an export modifier - an export declaration) all names are implicitly exported. If we stop emitting this marker, that behavior has to change, so privates remain private. Breaking that will be a breaking change, though! Declaration files like

type A = 1;
export interface B {}

allow importing A today, so forbidding that is a break - arguably a good one, but it'll be a break with a declaration file behavior we've had since approximately the origin of declaration files.

[fatcerberus]

And here I always assumed declaration files worked exactly like source files w.r.t. what’s exported - before today I would have confidently told anyone who asked that A there was internal to the file and not importable, just like it would be if that were a .ts file

[jakebailey]

Declaration files have really, really weird export semantics. Been trying to augment ts-eslint to handle that in typescript-eslint/typescript-eslint#8611 but it's definitely a battle, so not surprised to see this be wrong.

[weswigham]

It hasn't really needed to be something we've needed to think about since our declaration emitter started emitting privates and export {} automatically to work around the issue; it's weird, but it does "just work", back to ancient versions of TS.

[Dunqing]

This is weird. I am implementing the Isolated Declarations transformation in oxc. When I came across this empty export I thought it was a bug. it doesn't always occur, only non-exports referenced in the export statement generate export {}. so I tried searching in the TypeScript issues to confirm my suspicion.

So I want to ask, when a third-party tool wants to implement Isolated Declarations, does it also have to port this behavior?

[jakebailey]

Yes. If you're implementing isolated declarations, you should be using transpileDeclaration as your guide to correct output (on passing inputs).

[Boshen]

For future implementors of isolated declarations, you need port this "bug" as a feature 😁

We are already using the transpileDeclaration API to guide our implementation, but due to #51338, we assumed it is a bug and hence this PR.

[jakebailey]

Yeah; if you do find anything weird, please do report it so we can at least make sure it isn't actually a bug. e.g. oxc-project/oxc#3798 is likely a bug on our end is related to strictNullChecks.

Not quite sure where to document export {}, as this has been this way for ages and also applies to DT/hand-written types; I could have sworn this was documented on the website somewhere...