By converting schemas from TypeScript `interfaces` to `types`, we can minimize the reliance on `json.JsonObject`. This approach avoids the error "Type 'Schema' does not satisfy the constraint 'JsonObject'" caused by the missing index signature for type 'string' in 'Schema'.
Migrates the `@angular-devkit/build-webpack` jasmine tests to
`rules_js`. This requires wiring up in the pnpm workspace.
Additionally `typescript` is added as it was missing as a "peer
dependency" at runtime for `@ngtools/webpack`. This is expected, and
we're already adding other peer deps before this change.
This is necessary as with the new compilation, leveraging pnpm-linked
first party dependencies, there are cases **during migration** where
multiple locations of the same package exist. e.g.
- `@angular_devkit/architect/node_modules/@angular-devkit/core` (pnpm package output)
- `@angular_devkit/core` (plain js sources)
This is fine, and there is no risk of wrong types, and this should only
occur during migration anyway, but it causes a few type issues as
TypeScript is unable to emit proper types for inference. This is okay,
as we'd likely even want to make use of `isolatedDeclarations` at some
point, but we just add explicit types right now.
(also making `Builder` type more type safe, checking assignability
properly).
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.
* 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.
Currently the interop resulting target of a `ts_project` ends up not
necessarily working at runtime. This may be the case because a consuming
Node program may end up with mixes of `node_modules` dependencies from
`rules_nodejs` (old) and `rules_js` (new). This sounds fine at first
glance, but in practice can break very subtly because:
* Rules NodeJS leverages the linker, creating `node_module` directories
outside of Bazel, at runtime. These don't depend on symlink resolving.
* Rules JS puts real node module folders via Bazel actions. These rely
on `pnpm` non-hoisting layout, and symlink resolving.
As we can see there is a hard conflict with symlinks. They need to be
enabled with the new toolchain, but the other one doesn't enable symlink
resolution, and enabling is not possible as we'd otherwise risk escaping
the sandbox and cause even more subtle errors.
A good compromise solution is to automatically drop the `rules_js` node
module files/folder in the interop-`rules_nodejs` target and instead
brining in the equivalent `@npm//` dependencies from `rules_nodejs`.
This kind of keeps the logic similar to when not using `rules_js` or the
interop, and enables the simplest & safest mental model; and it works
compared to other solutions I tried with symlinking. Notably, we can't
keep both node module variants as the linker doesn't override existing
node module files from e.g. rules_js then (and would break then).
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)
The source code for the builders within the `@angular-devkit/build-webpack` package have been moved
into a `builders` subdirectory to more closely align with the structure of the builders in the
`@angular-devkit/build-angular` package. An initial `package.json` exports field definition has also
been added that currently continues to allow deep imports.
`compileComponents` is not necessary when using the CLI (as the templates are inlined) and just adds boilerplate code. So we can remove it from the test schematic and make it independent from `async/await` (only place we would have it in the CLI generated code, and in most Angular apps).
