Currently when operating within a pnpm workspace and leveraging the
schematic test runner, there are situations where e.g.
`@schematics/angular` cannot be resolved. Consider this pnpm node
modules structure:
```
packages/
pwa/
node_modules/@schematics/angular --> .pnpm-store/@schematics/angular/...
node_modules/@angular-devkit/schematics --> .pnpm-store/@angular-devkit/schematics/...
index_spec.js // trying to call external schematic `@schematics/angular`
```
This above setup will fail because `@schematics/angular` is attempted to
be resolved from within the devkit schematics code, which doesn't have
access, or a dependency on `@schematics/angular`. We can use the
specified collection of the test runner to determine a good "resolution
lookup site", similiar to how it happens with the real `ng update`
command.
Migrates `@angular-devkit/schematics` jasmine rules to the
native `rules_js` variant.
As part of this commit, we are performing a few adjustments that we've
discussed as preparation for this migration:
- cross package imports are always using the module name
- inside package imports are always using relative imports, matching
existing tests, fixing a few outliers.
Integrates `@angular/cli` into the pnpm workspace and wires up the
native `rules_js` rules.
One nice benefits that highlight here:
- `resolve` runtime dependency is only installed in the CLI folder, and
we can pull it from there. --> Locally managed deps! :yay:
This is necessary as `rules_js` requires this "common name" when dealing
with Yarn workspaces, linking first party dependencies automatically.
In the future, we may be able to send a PR to `rules_js` to support a
custom name somehow.
The `Rule` type has been updated to align with its intended functionality, allowing it to return a `Promise<Tree>`. Previously, this behavior was supported but not properly typed.
Closes#22783
* Removes `interop_deps` from the `ts_project` interop macro.
* Keeps `_rjs` suffix for now as we still need the interop targets for
e.g. `jasmine_node_test` and the `rules_nodejs` linker.
In follow-ups we can remove the suffix, and interop layer.
The `@angular-devkit/schematics` package has been migrated to the `rules_js` ts_project rule.
The tsconfig path mappings for the `@angular-devkit` scope have also been cleaned up now that
all the packages within this scope have been migrated.
The file system engine hosts for schematics were using a helper method to
read JSON files that was performing both an exist and read call. Besides
causing two file system calls, this also has a potential race condition
where the file may not exist by the time the read call is made. To avoid
this, a try/catch is used with the read call to handle the not existing
case.
Several smaller code changes to improve type information and remove now
unneeded code structures based on improvements to both Node.js, TypeScript,
and underlying dependencies.
The TypeScript `isolatedModules` option is now enabled for all TypeScript
code within the repository. As a result, all packages will now be built
with the option enabled. This does not affect projects created with the CLI
and is only related to the building of the actual Angular CLI code.
The `isolatedModules` option ensures that code can be emitted without the
TypeScript typechecker and allows tools other than TypeScript to potentially
be used. Code was updated to correct all errors after the option was enabled.
Additionally, some early code fixes were done to add function and accessor
return types to prepare for future `isolatedDeclarations` usage. More changes
would be needed to consider turning on `isolatedDeclarations`, however.
Updates for all angular.io links to the new angular.dev domain. Additionally, adjustment to new resources where the equivalent does not exist on the new site (e.g. Tour of Heroes tutorial)
All direct usage of rxjs has been removed from the FilterHostTree implementation.
This removes the need to import rxjs within the containing file. The recursive
logic has also been replaced with an iterative approach.
The schematics `UpdateRecorder` now uses the `magic-string` library directly instead
of delegating to another class (`UpdateBuffer`) which now effectively only wraps the
`magic-string`. This also allows for improved BOM handling and repeat conversion
of strings to and from `Buffer` instances.
Currently, when using `ng new` on Windows, users will get a number of `LF will be replaced by CRLF the next time Git touches it` warnings.
This commit, replaces the line endings in templates to be platform specific.
Closes#26764
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.
BREAKING CHANGE: deprecated `runExternalSchematicAsync` and `runSchematicAsync` methods have been removed in favor of `runExternalSchematic` and `runSchematic`.
