This change addresses an issue encountered when running external schematics from
a yarn pnp workspace. The function used to resolve a collection json using node
used recursion in a way that it effectively walked itself into an exception. Then,
if the exception is the type it expected, it would keep going. This was flawed
in that yarn with pnp throws a different type of error when it failed to load
the mis-constructed collection path
(e.g. `/node_modules/@schematics/angular/collection.json/package.json`).
`ENOTDIR` instead of `MODULE_NOT_FOUND`.
This process of intentionally / knowingly walking into an exception seems problematic in
general. So, I addressed it by first checking if the `schematics` entry in the package
is a relative path. If it is, then don't construct the collection path from that.
If entry is not relative, then assume it's pointing at another package and we need
to recurse to get to the actual collection path.
I've tested this in both yarn pnp and non-pnp environments.
This change addresses an issue encountered when running external schematics from
a yarn pnp workspace. The function used to resolve a collection json using node
used recursion in a way that it effectively walked itself into an exception. Then
if the exception is the type it expected, it would keep going. This was flawed
in that yarn with pnp throws a different type of error when it failed to load
the mis-constructed collection path (e.g. `/node_modules/@schematics/angular/collection.json/package.json`). `ENOTDIR` instead of `MODULE_NOT_FOUND`.
This process of intentionally / knowingly walking into an exception seems problematic in
general. So, I addressed it by removing the recursion that was used mainly because
there's a similar need to construct the collection path from a relative path in the
package.json as there is to construct the collection path from a relative path that's
passed in. Rather than leaning on the recursion to do this, I added the logic
at the time we pull the schematics path from the package, and move on.
Since the recursion was removed, the infinite recursion safety check at the start wasn't
needed anymore.
I've tested this in both yarn pnp and non-pnp environments.
Prepares the `@angular-devkit/schematics` package for the eventual change of enabling the
TypeScript `useUnknownInCatchVariables` option. This option provides additional
code safety by ensuring that the catch clause variable is the proper type before
attempting to access its properties. Similar changes will be needed in the other
packages in the repository prior to enabling `useUnknownInCatchVariables`.
The `_resolveReferenceString` abstract method of the `FileSystemEngineHostBase` class now has a third parameter
that provides the collection description of the schematic currently being resolved. This allows the resolver to
use any fields/options present within the collection description to adjust the resolution of the schematic. The
`encapsulation` optional field is also added to the `FileSystemCollectionDescription` type which will in the future
allow control of the `@angular/cli` VM context wrapping on an individual schematic collection basis.
This change first attempts to resolve a schematic referenced via the external schematic rule from the requesting schematic collection. This allows schematic packages that are direct dependencies of another schematic package to be used with the external schematic rule without manual package resolution code within the schematic.
Closes#18098Closes#11026
With Angular CLI version 8, migrations cannot be re-run with the
`--migrate-only` flag as there was a recent regression introduced
in e406f00909 (diff-0d0a748fb9a38a7ccde08d9b42e70bce) as it now passes
a normalized platform path to the `engine.createCollection` call.
This breaks as there is incorrect logic within
`node-modules-engine-host` that causes the schematic collection to be
searched within the `package.json#schematics` entry. This is incorrect
as migration schematics specify their migration schematics in a separate
schematic collection file which is part of `package.json#ng-update`.
Fixes#14565
