-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Resolve only relative references in open files on syntax server #39476
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
eb8a109
to
56fb305
Compare
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 56fb305. You can monitor the build here. |
Looks like there's no packed build because of quote preference changes in a fourslash test. Click for log
|
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at db10229. You can monitor the build here. |
Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running |
Hey @sheetalkamat, something went wrong when looking for the build artifact. (You can check the log here). |
@andrewbranch can you please review again. I had to add another commit to ensure we aren't included triple slash reference tree (but including them only from open file) since we removed @DanielRosenwasser @RyanCavanaugh what is your take on this. do we want to get this in? |
Yes, I think we want to get this in, but I have kind of been worrying about two scenarios:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest change makes sense to me 👍
hasChangedAutomaticTypeDirectiveNames, | ||
includeTripleslashReferencesFrom: maybeBind(host, host.includeTripleslashReferencesFrom), | ||
trace: maybeBind(host, host.trace), | ||
resolveModuleNames: maybeBind(host, host.resolveModuleNames), | ||
resolveTypeReferenceDirectives: maybeBind(host, host.resolveTypeReferenceDirectives), | ||
useSourceOfProjectReferenceRedirect: maybeBind(host, host.useSourceOfProjectReferenceRedirect), | ||
}; | ||
if (host.trace) { | ||
compilerHost.trace = message => host.trace!(message); | ||
} | ||
|
||
if (host.resolveModuleNames) { | ||
compilerHost.resolveModuleNames = (...args) => host.resolveModuleNames!(...args); | ||
} | ||
if (host.resolveTypeReferenceDirectives) { | ||
compilerHost.resolveTypeReferenceDirectives = (...args) => host.resolveTypeReferenceDirectives!(...args); | ||
} | ||
if (host.useSourceOfProjectReferenceRedirect) { | ||
compilerHost.useSourceOfProjectReferenceRedirect = () => host.useSourceOfProjectReferenceRedirect!(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
❤️
Co-authored-by: Daniel Rosenwasser <[email protected]>
Should we cap this to say resolving 10 module names per file or something. But i am not sure if anyone uses those many relative imports in the file. Dont have data to cap on number of say that we should handle it.
Do you think we should only use single file as open file (file thats last opened or asked to update project based on semantic operation requested). I did consider this but that just means we wont reuse the program as often if say user navigates to new file using go to def and hovers over certain item and goes back as an example. The current one keeps program updates to minimal and keeps on reusing things till it can.. leading to less program updates and more info. I am open to suggestion though. |
Let's do it in a later pass, I'd like to try to get this in the next nightly so that we can get feedback as soon as we can.
Yeah, that's a good point. If this can unblock those strenuous cross-project program loads, I think the responsiveness will make up for it. |
Ok then merging. |
Resolve only relative module references in the open files