fix: keep a peer dependency out of dependencies when a sub path resolves to it - #519
Merged
Merged
Conversation
…olves to it A package imported both bare and by a sub path produces two `npm:` specifiers. Only the bare one matches the user's mapping, so the sub path got an auto derived mapping with `peerDependency` unset and the package ended up in both `dependencies` and `peerDependencies`.
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.
Found while checking whether #433 still reproduces. The cases reported there are all fixed on
main, but a neighbouring one isn't.A package imported both bare and by a sub path produces two
npm:specifiers:Only the bare specifier matches the user's mapping, so the sub path gets an auto derived
PackageMappedSpecifierwithpeer_dependency: false.get_dependenciesemits both entries, andpackage_json.tsfilters that same list into each section, so the package lands in both:npm then installs it as a regular dependency, which is the symptom #433 describes.
Being a peer dependency is a property of the package in the package.json rather than of an individual specifier, so a name marked as one anywhere stays one. The entries are then identical and collapse in the existing
dedup().Mapping
npm:pkg@^1when the source only importspkg/substill errors with "specifiers were indicated to be mapped to a package, but were not found". That seems right — the specifier that's actually imported is the one to map, which is whatsubPathis for.