auto-import types #12225
Draft
auto-import types #12225
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
turadg
force-pushed
the
ta/type-auto-imports
branch
from
0d80709 to
ceac2a8
Compare
turadg
force-pushed
the
ta/type-auto-imports
branch
from
ceac2a8 to
ac67de5
Compare
mergify bot
added a commit
that referenced
this pull request
Nov 17, 2025
refs: #9005 ## Description This changes all tsconfig projects to use `moduleResolution: 'NodeNext'`, freeing us of ambients! There are still some globals via `exported.js` that we can burn down later but at least those are explicit. (The previous moduleResolution, 'bundler', was necessary because of our dependence on ambients. It's the mode that assumes everything will be turned into one giant bundle, so whatever hacks and heuristics the local TSC has to do to get the types to resolve is okay. But we actually do publish separate packages so need more strict type resolution behavior.) I used the hacky script in #12225 but am not proposing to merge that. We might need to run it again when getting off `exported.js` but we can either run it from the branch or do some more (separate) work to make it trunk-worthy. That script uses the TS language server to iterate over files and do the "auto-import" that VS Code does. By changing the moduleResolution from 'bundler' and running that, necessary types are auto-imported. When there's a duplicate name it doesn't always get the right one so some manual fixups were necessary. After doing this for every module in the repo, I was able to change the default so they all are 'NodeNext' now. ### Security Considerations none ### Scaling Considerations none ### Documentation Considerations Any downstream relying on the `types-ambient.js` exports will fail. The solution is just to import explicitly. I think that's a fine change to impose. ### Testing Considerations CI Nothing downstream will fail until it updates to a newer release and the fix for any ambients will be trivial. ### Upgrade Considerations does not affect chain
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
refs: #5760, #9005
Description
Script to auto-import types using TypeScript language server. This can be used to change the moduleResolution to NodeNext, which breaks the ambient imports, and then run this auto-repair. The inline
@importare fixed up by the new eslint rule to group-jsdoc-imports.Security Considerations
Scaling Considerations
Documentation Considerations
Testing Considerations
Upgrade Considerations