-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Suppress resolvedUsingTsExtension during loadModuleFromDirectory #52189
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
@typescript-bot test this |
Heya @jakebailey, I've started to run the perf test suite on this PR at 7f4baf6. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the extended test suite on this PR at 7f4baf6. You can monitor the build here. |
Heya @jakebailey, I've started to run the diff-based user code test suite on this PR at 7f4baf6. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the diff-based top-repos suite on this PR at 7f4baf6. You can monitor the build here. Update: The results are in! |
Heya @jakebailey, I've started to run the parallelized Definitely Typed test suite on this PR at 7f4baf6. You can monitor the build here. |
@jakebailey Here are the results of running the user test suite comparing Everything looks good! |
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 the only callsite where we construct a path and feed it into nodeLoadModuleByRelativeName
where that path doesn't come from a user-supplied specifier, right? Right.
Heya @jakebailey, I've run the RWC suite on this PR - assuming you're on the TS core team, you can view the resulting diff here. |
I think so? Interestingly, it's also the only place where we pass |
I think the meaningful thing is whether the module name you’re currently trying to resolve actually came from an import module specifier in source code (this is the only time Actually, it’s a bit more nuanced than that. What matters is whether the file extension itself came from an import module specifier. The module name you’re resolving could be a combination of source text and path mapping config text constructed via a wildcard substitution, e.g.:
Assuming both of these resolve, |
I'm basically just a monkey at a typewriter on this one having never touched this code before... 😅 Are you saying that this fix isn't complete/right and I should be fixing things up? (I'll add that case in and see what happens.) |
I added what I think is the test you suggested? (Though, maybe not, given this bug is only in the node10 resolver? Maybe?) |
@jakebailey Here they are:
CompilerComparison Report - main..52189
System
Hosts
Scenarios
TSServerComparison Report - main..52189
System
Hosts
Scenarios
StartupComparison Report - main..52189
System
Hosts
Scenarios
Developer Information: |
@jakebailey Here are the results of running the top-repos suite comparing Everything looks good! |
Fixes #52182
This is the fix suggested by @weswigham; the state prop could also be undefined and implicit to avoid setting false everywhere, but I am guessing this makes it slower somehow.