The strategy tests are extremely time-sensitive with regards to the RxJS
job logic executing, and the tests currently rely on `setImmediate` to
flush/trigger job execution. This seems to be rather unstable via Remote
execution, and sensitive to changes with the execution (e.g. injecting
source map support or not), so we are stabilizing the tests further by
having better time delays for job execution, and by using `setTimeout`
for flushing. This seems very sufficient.
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:
Instead of using `rules_nodejs` interop and the linker at runtime, the
test target is migrated to the new `jasmine_test` rule, leveraging the
pnpm workspace for first-party dependencies.
Note that in the future we may be able to rename the local node modules
to something more clear. e.g. `:local_modules/@angular-devkit/core`, but
for now this is not possible :(
This commit shows how similar packages can be migrated in the future.
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.
Migrates the `@angular-devkit/architect` package to the `rules_js` npm
package rule, consuming the direct `rules_ts` output JS files.
Notably, substitution is FAR different than what it used to be with
`rules_nodejs`, so we needed some extra work to leverage `make_template`
for substitutions in `package.json` files. **Keep in mind** that for
now, this does not apply to any other files; so we only substitute in
the `package.json`, but not in e.g. `.js` files as before. We will
follow-up on this.
The other jq merging/filtering for snapshot or tar references in
`package.json` files is kept as is, and is temporarily duplicated. This
is acceptable as the migration should be pretty smooth and quick.
* 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.
To avoid the need to perform Node.js resolution for the typical case of a relative
builder schema, a check is now performed to determine if a schema path within the
build manifest appears to be relative.
In our dev-infra sync we decided that we want to have less
ambiguous naming for node modules from the workspace root vs. node
modules that are local to the package.
Consider the confusion between: `//:node_modules` and `:node_modules`.
This commit fixes this by naming the workspace `node_modules` as
`:root_modules`. This does not have an effect on runtime of NodeJS
output because `rules_js` continues to lay out the root modules as
`/node_modules` folder; as it should.
This commit updates the architect devkit package code to use
`ts_project`. We specificially don't migrate the jasmine node test yet
as we want to experiment further with the incremental migration.
We recently introduced the ability to pass object values from the
command line (#28362). @clydin noticed that the initial behavior
didn't work well for `--define`: It completely replaced all values
even if just one of multiple defines is specified.
This updates the architect to support merging of object options.
If both the base option (e.g. from `angular.json`) and the override
(e.g. from a CLI `--flag`) are objects, the objects are merged.
See: https://github.com/angular/angular-cli/pull/28362
I often struggle with spacing around block comments, so I've decided to add the `lines-around-comment` lint rule to help manage this.
For more details, see the https://eslint.style/rules/js/lines-around-comment
Due to bazel rules_nodejs caching, several additional `JSON.parse` usages were not
caught in the first set of fixes. These have now been addressed. Also,
the `must-use-promises` rule has been patched to match the behavior of the
`@typescript-eslint/no-floating-promises` for consistency.
The bazel option `suppressTsconfigOverrideWarnings` was also removed from the
`tsconfig` as it is a no-op and was previously used for now removed feature.
Test files are currently excluded from the `JSON.parse` rule to avoid large
changes to test code.
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)
When resolving a builder alias, the base path for the resolution will now
use the containing package. This prevents potential resolution failure due
to varying package manager installation strategies.
A builder's manifest definition within a package (typically `builders.json`) can now contain
a string value that will be used as a builder specifier when loading the named builder. This
allows a builder name to be aliased to another builder. The other builder may also be in
another package.
The build resolution logic has also been updated to remove use of the global `require` to
support eventual direct ESM usage.
The `buildTarget` options for both the `dev-server` and `extract-i8n` builders
now have default values that reflect the recommended and new project generated
values. The defaults are as follows where `<current-project>` is the name of the project
where the `dev-server` or `extract-i18n` builder target is located:
* `dev-server` --> `<current-project>:build:development`
* `extract-i18n` --> `<current-project>:build`
Additionally, abbreviated target specifiers are now supported for these
options. This allows target specifiers such as `::production` which would expand
to `<current-project>:build:production` for either builder.
Abbreviated target specifiers are only supported for the `buildTarget` option in
the `dev-server` and `extract-i18n` builders.
The dynamically compiled ESM import helper is now cached to prevent the need
to recompile the helper function everytime a load ESM helper call is made.
This helper is currently used to workaround dynamic import limitations with
the TypeScript compilation output. Once the build process is updated, it will
no longer be required.
G3 is now using RXJS version 7 which makes it possible for the CLI to also be updated to RXJS 7.
NB: this change does not remove all usages of the deprecated APIs.
Closes#24371
Use promise based methods to reduce RXJS usage and boiler-platting.
BREAKING CHANGE: Several changes to the `SchemaRegistry`.
- `compile` method now returns a `Promise`.
- Deprecated `flatten` has been removed without replacement.
When performing a release via the dev-infra `ng-dev` tooling, the release
builds for the packages that will be published are now performed using bazel.
Prior to this, the release builds were performed using a custom build script
that programmatically invoked TypeScript APIs. The Bazel build and discovery
process for the releasable packages is performed by a script that is based on
the scripts from components and framework repositories. Several small modifications
were performed to match the behavior and structure of the cli repository:
* Use of `packages` as the source root in the bazel query
* Use of `pkg_npm` rule in the bazel query
* Partial transition to native Node.js `fs` APIs instead of `shelljs`
* Directory creation per package when copying output (supports multiple package scopes)
* Copying of archives (tgz) for each package
The snapshot and local build capabilities are not modified as part of this change
but will be merged in a followup as part of a larger transition to use bazel
throughout the package build process.
Currently, if an architect builder does not provide any results, the CLI will crash
trying to access an error message property on the result. Instead architect will now
provide a default failure result `{ success: false }` in the event that the builder
exits prior to generating a result. Thrown errors continue to be propagated as before.
All analytics is now in the @angular/cli package
BREAKING CHANGE: analytics APIs have been removed without replacement from `@angular-devkit/core` and `@angular-devkit/architect`.
The dev-infra build tooling is now decoupled from `ng-dev`. This will
make it easier to update `ng-dev` without necessarily needing to upgrade
the whole build system, Bazel etc. This is useful when e.g. new release
tool features have been added and should also be ported to active LTS
branches.
Waiting to complete the builder until the next tick allows the logging
subscription to flush and provide queued logging entries to the builder
consumer.
Prepares the `@angular-devkit/architect` 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`.
