* build: disconnect `@npm` workspace from main project
This will speed up significantly as we don't need to fetch all
dependencies again just for the `@npm` repository that is at this point
only leveraged by the `ng_package` rule for some of its dependencies.
This commit allows us to drop the `yarn.lock` and Aspect lock files, and
allows us to independently migrate `ng_package` to `rules_js`.
It also allows us to drop the `_rjs` TS interop layer in follow-up commits.
* build: drop `_rjs` suffix from `ts_project` targets
We don't need the `ts_project` interop in principle
at this point. We only have one remaining instance left for the SSR
`ng_package` integration. This commit cleans up all usages.
* build: remove yarn
* build: avoid duplicated dependencies at top-level
`rules_js` seems to be sensitive if there are similar versions of the same
package installed, but with differently matched peer dependencies. This
is fine because we can (and should long-term) move those dependencies to
their package-local `package.json` files. This commit unblocks the
migration and highlights how we can move deps to the individual packages
in the future.
* build: update checkout github action
This will allow us to use pnpm.
* build: update node to avoid strict-engines error caused by `npm`
Avoids:
```
Lockfile is up to date, resolution step is skipped
ERR_PNPM_UNSUPPORTED_ENGINE Unsupported environment (bad pnpm and/or Node.js version)
Your Node version is incompatible with "npm@11.2.0".
Expected version: ^20.17.0 || >=22.9.0
Got: v20.11.1
```
Note that we won't update the WORKSPACE test version as that would mean
we need to update the Node engines for shipped packages; and we can't do
this right now without introducing a breaking change.
* build: fix missing dependency for spec bundling
The beasties JS sources weren't available for bundling in the
`bazel-bin`, and this surfaced in RBE. This commit fixes this.
As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:
- we will still support contributors on Windows, and we believe we will
be improving and streamlining the experience here
- we will continue testing the Angular CLI for our Windows users. We are
aware of the many Windows users using the `ng` CLI.
What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!
---
For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows `ng` CLI testing!
This is what this change mostly does.
Notably, two things are missing here and will be followed up:
- caching of the e2e tests on Windows is not properly functioning yet.
- caching of the WSL node modules + nvm is not working properly yet.
Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our `rules_js` migration.
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`.
