fix(resolver): resolve TypeScript imports of declaration files - #511
Merged
Merged
Conversation
`packages/types/Calendar.d.ts` is extracted as the module `packages.types.Calendar.d`, while code imports it as `@calcom/types/Calendar` or `./Calendar`. The TypeScript branch of resolve_import_target now tries each candidate as written and then with the `.d` suffix — the order TypeScript resolves in, so an implementation beside its declaration wins. Node ids are left unchanged. The candidate logic moves from SymbolIndex to module-level functions so the class stays under the god-object threshold. Closes #507 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Code Review
This pull request enhances TypeScript import resolution by adding support for declaration files (.d.ts). It replaces the previous workspace import resolution with a new _resolve_typescript_import helper that checks both the exact import target and its declaration counterpart (ending in .d), ensuring that implementation files take precedence over declaration files. A new test suite has been added to verify these changes. I have no feedback to provide on this pull request.
|
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Closes #507.
Problem
The extractor strips only the last extension, so
packages/types/Calendar.d.tsbecomes the modulepackages.types.Calendar.d. Code imports it as@calcom/types/Calendar(or./Calendar), with no.d. After #506 mapped@calcom/typestopackages.types, the candidatepackages.types.Calendarstill matched no node.Fix
The TypeScript branch of
resolve_import_targettries each candidate (the target itself, then the workspace-package candidates from #504) as written, then with.d. That is the order TypeScript resolves in, so an implementation beside its declaration wins.Node ids are not changed: stripping
.dwould rename every declaration node in existing graphs and givefoo.tsandfoo.d.tsone id.The candidate logic now lives in module-level functions (
_resolve_typescript_import,_workspace_candidates) rather than onSymbolIndex, which would otherwise cross the god-object threshold intest_architecture.py. Same approach as #506; the baseline is not extended.Tests
tests/unit/test_resolver_ts_declarations.py:.d.tsMeasured on cal.com
@calcom.*IMPORTS targetspackages.types.Calendar.dmake format lint type-check doc-coverage pytest: all green (2716 passed, 1 xfailed).🤖 Generated with Claude Code