fix(cdk/schematics): avoid runtime errors thrown by devkit tree when TypeScript tries non-existent path #22982
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.
TypeScript resolves modules using a rather complicated module
resolution algorithm. The algorithm tries various paths to
determine a possible entry-point for a module. e.g. it also
respects a containing
package.json
file, or respects the closestnode_modules
parent directory.In some situations, TypeScript could end up trying a path where
a parent directory segment resolves to an existent file. e.g.
consider the following directory structure:
TypeScript could end up trying paths like:
node_modules/my-pkg/styles.css/package.json
ornode_modules/my-pkg/styles.css/a/b/package.json
. This depends on howthe module resolution executes, and how the module is referenced.
In the example above though, TypeScript checks if the files exist. Our update
logic delegates this check to our virtual file system. The virtual file
system currently would throw an error by accident as it walks up the
path and discovers that
styles.css
is not a directory, but a file (https://github.com/angular/angular-cli/blob/master/packages/angular_devkit/schematics/src/tree/host-tree.ts#L321)This results in an error as seen in
#22919. This seems to have been introduced
accidentally with #21161.