fix(ngcc): compute the correct package paths for a target entry-points #40376
Conversation
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
petebacondarwin
added
action: review
15 tasks
JoostK
approved these changes
Jan 9, 2021
packages/compiler-cli/ngcc/src/entry_point_finder/targeted_entry_point_finder.ts
Outdated
Show resolved
Hide resolved
Previously, if there were path-mapped entry-points, where one contaied the string of another - for example `worker-client` and `worker` - then the base paths were incorrectly computed resulting in the wrong package path for the longer entry-point. This was because, when searching for a matching base path, the strings were tested using `startsWith()`, whereas we should only match if the path was contained in a directory from a file-system point of view. Now we not only check whether the target path "starts with" the base path but then also whether the target path is actually contained in the base path using `fs.relative()`. Fixes angular#40352 Fixes angular#40357
petebacondarwin
force-pushed
the
ngcc-path-containment-issue-40352
branch
from
09c9c56 to
7e7769a
Compare
|
Since the commit message needed updating I just amended the commit. |
petebacondarwin
added
action: merge
atscott
pushed a commit
that referenced
this pull request
Jan 11, 2021
…40376) Previously, if there were path-mapped entry-points, where one contaied the string of another - for example `worker-client` and `worker` - then the base paths were incorrectly computed resulting in the wrong package path for the longer entry-point. This was because, when searching for a matching base path, the strings were tested using `startsWith()`, whereas we should only match if the path was contained in a directory from a file-system point of view. Now we not only check whether the target path "starts with" the base path but then also whether the target path is actually contained in the base path using `fs.relative()`. Fixes #40352 Fixes #40357 PR Close #40376
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Previously, if an entry-point started with the string of another package that
is included in
pathsmappings, then the base path was incorrectly computedresulting in the wrong package path for the entry point.
Now we not only check whether the target path "starts with" the base path
but then also whether the target path is actually contained in the base path
from a file-system directory point of view.
Fixes #40352
Fixes #40357