-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Source files not affected by all module resolution options #55790
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
dc1a244
to
63226c2
Compare
This comment was marked as resolved.
This comment was marked as resolved.
@typescript-bot test this |
Heya @sheetalkamat, I've started to run the diff-based user code test suite on this PR at 6a43bc1. You can monitor the build here. Update: The results are in! |
Heya @sheetalkamat, I've started to run the diff-based top-repos suite on this PR at 6a43bc1. You can monitor the build here. Update: The results are in! |
Heya @sheetalkamat, I've started to run the diff-based top-repos suite (tsserver) on this PR at 6a43bc1. You can monitor the build here. Update: The results are in! |
Heya @sheetalkamat, I've started to run the regular perf test suite on this PR at 6a43bc1. You can monitor the build here. Update: The results are in! |
Heya @sheetalkamat, I've started to run the diff-based user code test suite (tsserver) on this PR at 6a43bc1. You can monitor the build here. Update: The results are in! |
@sheetalkamat Here are the results of running the user test suite comparing There were infrastructure failures potentially unrelated to your change:
Otherwise... Everything looks good! |
@sheetalkamat Here they are:
CompilerComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
tsserverComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
StartupComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
@sheetalkamat Here are the results of running the user test suite comparing Everything looks good! |
@sheetalkamat Here are the results of running the top-repos suite comparing Everything looks good! |
1 similar comment
@sheetalkamat Here are the results of running the top-repos suite comparing Everything looks good! |
…only options that affect sourceFile
…wont change and ready to use.
6a43bc1
to
7be4b04
Compare
Can you give some more details on what this change is regarding in the PR description? I can see baselines changing, but I'm not entirely sure what was wrong before. |
@DanielRosenwasser Was just in process of writing |
@@ -1,4 +1,5 @@ | |||
[ | |||
"Module 'ph' was resolved as locally declared ambient module in file '/a/b/node_modules/@types/node/ph.d.ts'.", |
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.
This is something to do with how we compile the program twice. which i dont understand clearly but when i run the scenario as "tsc" this trace is expected and was missing before.
@@ -69,7 +69,7 @@ Info seq [hh:mm:ss:mss] Open files: | |||
Info seq [hh:mm:ss:mss] FileName: /user/username/projects/myproject/index.ts ProjectRootPath: undefined | |||
Info seq [hh:mm:ss:mss] Projects: /user/username/projects/myproject/tsconfig.json | |||
DocumentRegistry:: | |||
Key:: undefined|undefined|undefined|undefined|false|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined|undefined | |||
Key:: undefined|undefined|undefined|false|undefined|undefined|undefined|undefined|undefined|undefined |
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.
This just shortens the key because now many of the module resolution affecting options are not accounted in sourceFile sharing
Just to confirm my understanding, this moves properties off of |
It seems like this could actually inflate memory usage (you can see a couple modest increases in some of the perf tests) when there are many programs with identical |
I was thinking as a next step we could try and use module resolution cache to get the result instead of storing it in the program but that needs some thinking( since in most cases resolution already exists in the cache) storing on document registry would need so comparisons and invalidation logic that would lead to similar issue as I am trying to fix here (resolving type reference of auto type from different locations when two projects don’t specify type roots ) |
Stops taking dependency on all module resolution options when sharing sourceFiles and instead moves
resolvedModules
andresolvedTypeReferenceDirectiveNames
fromsourceFile
toProgram
so it is safe by program to copy the resolutions across.This came up as part of testing with #54785 where
axion
and some more (which i dont recollect) didnt pass incremental resolution check. This is shown in ddaf1c7 specifically (ddaf1c7#diff-215d7c39ab1082f80d4c3a4f1c8bd9dd1c9ccb1c6450192bbaf409b8e5376579R140) where the resolved module on sourceFile changes and results in issues program referencing other resolution.The issue here lies in fact that "as type" resolution takes into account typeRoots and if config had it its good and used as a key for affecting resolution but if user didnt specify it depends on "config file location" if present otherwise "currentDirectory" . This is issue because you could include either by types or default types (matching in both projects) a type thats in parent directories
node_modules/@types
but then that type could includetypes
directive of saynode
which in both projects will be resolved say from config location which is different and if those directories have their ownnode_modules/@types/node
then the location which is picked will depend on which project is picked firstInvestigated few options for this
node_modules/@types
in the key but that means on eachnpm install
we would need to update module resolutions from scratch as its change in "key" and parse "sourceFiles" so that doesnt seem practical