-
Notifications
You must be signed in to change notification settings - Fork 12.6k
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
Only filter ignored paths from module specifier generation if there exists a better option #43024
Conversation
…xists a better option
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.
Is the assertion that triggered the crash still correct to have? Is this function no longer able to return undefined
in the cases that feed into that assertion?
Does this fix #43011 too? Looks potentially similar, mentions |
Yes. Fixes #43011. |
Yeah, the assertion is correct, and the function I changed is |
@typescript-bot cherry-pick this to release-4.2 |
Heya @andrewbranch, I've started to run the task to cherry-pick this into |
@typescript-bot cherry-pick this to release-4.2 |
Heya @andrewbranch, I've started to run the task to cherry-pick this into |
Hey @andrewbranch, I've opened #43032 for you. |
Component commits: bd2fd3b Only filter ignored paths from module specifier generation if there exists a better option a687bae Nit 7597f52 Merge branch 'master' into bug/42785 Co-authored-by: Andrew Branch <[email protected]>
Fixes #42785
Fixes #43011
Sometimes the resolver can’t come up with a module specifier that doesn’t have an “ignored path” (like
.pnpm
or.prisma
) in it. In those cases, we need to use the undesirable ignored path. In @dlannoye’s repro, the.pnpm
path never actually manifests in a declaration file—the resolver separately finds an accessible re-export and uses that, but there was nevertheless an assertion that we could come up with something for the declaring module itself. The test case included is based off of @flybayer’s repro. This case does result in a type serialization that referencesnode_modules/.prisma
directly, which isn’t great, but that would have happened in 4.1 and earlier as well. (The real example from @flybayer hasnoEmit
enabled, so in fact neither real-world case actually exhibits bad behavior with this PR. And I think for the Prisma case, it’s not strictly harmful if declaration files reference".prisma"
anyway, since that folder will have to get created during build/install for"@prisma/client"
to work.)