* 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.
Migrates the `@angular-devkit/build-angular` tests to `rules_js`. This
was a rather larger undertaking as the tests were very reliant on e.g.
the directory structure or specific node module layout; so some changes
were needed.
- the Sass files include a much larger file header now. That is because
the npm Sass files have much larger paths, given being inside a
symlinked pnpm store directory. E.g.
```
/*!**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************!*\
!*** css ../../../../../node_modules/.aspect_rules_js/css-loader@7.1.2_webpack_5.97.1/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[1]!../../../../../node_modules/.aspect_rules_js/postcss-loader@8.1.1_1462687623/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[2]!./src/test-style-a.css?ngGlobalStyle ***!
\**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************/
.test-a {color: red}
```
- Similarly to above, hashed chunk files can change given different
paths of e.g. Webpack, or external sources.
- Tests for verifying the lazy module chunks may enable
`preserveSymlinks` just to make the chunk names shorter and easier to
verify, avoiding truncatd super long paths to the e.g. pnpm stores
again.
- the ngsw-worker.js file cannot be copied using `copyFile` as that
results in permissions being copied as well. In Bazel, now that
the npm files are properly captured, are readonly, so subsequent
builds (e.g. the watch tests) will fail to copy/override the file
again! Reading and writing the file consistently seems appropriate.
- Tests relying on puppeteer and webdriver-manager worked in the past,
by accident, because postinstall scripts (from e.g. puppeteer) were
able to modify content of other packages (e.g. the puppeteer-core
cache of browsers then). This does not work with `rules_js` anymore,
so we need to keep the cache local to the puppeteer postinstall
script. This requires a little trickery right now to ensure resolution
of the browsers at runtime works..
- server tests did miss the `node` types to be explicitly listed (as
they would be in a fresh project), and this caused failures. Likely
because we no longer patch resolution.
- avoid npm-module style imports from tests within the same package.
This is not allowed with `rules_js` and also is inconsistent.
Migrates `@angular/build` tests to native `rules_js`. This involves
wiring up the package in the pnpm workspace, as well as adding some
missing dependencies that previously weren't needed due to less
efficient per-package isolation of transitive deps.
In addition, we need to explicitly specify `ssr` as dev dependency as we
are not auto-installing peer deps, and the dependency is needed for some
server SSR tests.
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.
This fixes an issue where protractor integration tests are failing with
```
[07:38:37] I/direct - Using ChromeDriver directly...
[07:38:39] E/launcher - unknown error: Chrome failed to start: crashed.
(unknown error: DevToolsActivePort file doesn't exist)
```
To improve type-checking and reduce hard to diagnose errors when using the new
`production`/`development` conditions, the set of conditions used by the bundler
are now also synchronized with those used by TypeScript. This helps ensure
that type mismatches are avoided by type-checking against the actual file that
will be bundled into the output.
Ensures that we consistently set "development" for non-optimized and
"production" for optimized builds. This is consistent with other
bundlers (Vite/webpack/parcel/...).
To reduce duplicate code within tests for rebuild/watch scenarios, a new
helper has been added to the builder test harness. This helper allows
passing in an array of test case functions that are executed in order per
rebuild. The development server's watch option tests have been updated to
use the new helper.
In some environments, e.g. containers or in some cases macOS,
headless Chrome may not work with the sandbox enabled. This exposes
an escape hatch to run tests in those environments.
Example use:
```sh
yarn bazel test \
//packages/angular_devkit/build_angular:build_angular_karma_test \
--test_env=PUPPETEER_EXECUTABLE_PATH="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \
--test_env=CHROME_NO_SANDBOX=1
```
The `browserTarget` option has been removed as part of the refactoring process. This option was part of a private API and is no longer used. Projects relying on this option should migrate to using the `buildTarget` option.
BREAKING CHANGE: The `browserTarget` option has been removed from the DevServer and ExtractI18n builders. `buildTarget` is to be used instead.
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)
Newly generated projects will now use ECMAScript standard class field behavior by default.
If the legacy TypeScript behavior is required for a new project the `useDefineForClassFields`
TypeScript option can be set to `false` within the application's `tsconfig`. This should
be uncommon, and if needed, it is recommended to adjust code to match standard behavior where
possible.
The builder testing infrastructure and harness has been moved out of the
`@angular-devkit/build-angular` package and into a separate bazel only
module. This allows the testing code to be shared with other packages
within the repository. It also removes test only code from within
the package that is not specific any of the included builders.
