fix: detect and internalize types in more cases

[kalvenschraut]

• This PR contains AI-generated code, but I have carefully reviewed it myself. Otherwise, my PR may be closed.
  • I understand that my PR is more likely to be rejected or requested for changes if it contains AI-generated code that I do not fully understand.

Description

Try handle namespace type imports and make sure they are internalized along with other types that are used from internal .d.ts files that do not have export { } in them meaning they are considered imported per microsoft/TypeScript#57764

Linked Issues

tries to address issues I opened on tsdown's repo
rolldown/tsdown#743
rolldown/tsdown#744

Additional context

As I indicated I had AI look into this with me overseeing and guiding it. Going mark this as an initial draft to hopefully get feedback while I review and make any changes I see on review.

[kalvenschraut]

I did look over everything and nothing glaring that i see but I don't have a lot of context to know if it is the right fixes or now hoping to get some feedback. My original issues actually stemmed from me having dependencies as dev dependencies in a monorepo package that should have really been peer dependencies, but since I use catalog pnpm deps to make sure everything stays in sync and dont use the package outside of the monorepo workspace I never ran into issues. It seems like tsdown/rolldown-plugin-dts will internalize types so I figured this was the correct approach in that scenario

[sxzz]

Thanks for tackling this — the export = namespace pattern and ambient .d.ts type resolution are real issues worth fixing.

However, the current implementation has several concerns:

1. hasExplicitExportStatement only detects empty export { }, missing other export forms that also make TS treat a file as a module.
2. extractNamespaceMembers collects non-exported internal members, which would leak private types in the output.
3. Auto-exporting all declarations from node_modules .d.ts files is too aggressive — should be scoped to actually-referenced types.
4. Hardcoded reserved keywords list — use @babel/types utilities instead.
5. Snapshot regressions in existing tests — likely needs a rebase onto latest main.
6. type-only-import test fixture doesn't actually exercise the scenario it claims to test.

The problems being solved are valid, but the approach needs rethinking. I'd suggest a more targeted solution that only exports types that are actually imported by the consumer, rather than blanket-exporting everything from ambient files.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/rolldown-plugin-dts@175

commit: 3dffe91

[kalvenschraut]

for the export = namespace changes, I had to step back and reapproach them. After some thought I am thinking that rewriting the import to refer to the namespace and export the namespace explicitly is likely a more ideal direction from the two I could come up with AI's help. With the alternative was the original approach and keeping the import as is but generating a ton of type alias's for the namespace imports. The only question I have with this is it exported the the namespace members are not being treeshaken after being pulled in or is that something else I would somehow handle?

Need to try tackle the ambient .d.ts types again, not sure if I will get that where i want it tonight

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	mock-logger@​1.0.0
	mock-db@​1.0.0
	mock-framework@​1.0.0

View full report

[kalvenschraut]

marked as a draft as I have something mostly working but noticing some cases not covered that need to be fixed.

Would be appreciated to get feedback though to make sure I am heading in the right direction

[kalvenschraut]

There was one more issue I was trying to resolve that I noticed in my company's repo but that is resolved when updating to rolldown rc3 so going call this ready for review. I guess I did have the AI try simplify some things in the types as it ended up changing one of the rollup tests because of that IDK if that is a big problem or not. I was trying get it to not make uneeded namespaces which I thought were from my changes but maybe it wasnt.

[kalvenschraut]

hmm actually noticed that I see have type problems in my companies code base with rc 3, investigating. It is semi related to rolldown/tsdown#755 as if I have it marked as a peer/prod dep it works just fine but once my @types/json-schema is internalize type issues are coming up. if I determine this is a problem not related to this PR I will make a separate one. Realized the other problem was more related to declare module internalization issues as there is already an issue for this so not related