BREAKING CHANGE: Node.js v16 support has been removed
Node.js v16 is planned to be End-of-Life on 2023-09-11. Angular will stop supporting Node.js v16 in Angular v17.
For Node.js release schedule details, please see: https://github.com/nodejs/release#release-schedule
This commit introduces experimental support to pre-render (SSG) and app-shell generation to the new application builder.
- `appShell`: option which can have a value of `true` or `false` has been added to support generating an app-shell.
- `prerender`: option which can have a value of `true`, `false` or an object with the below listed properties can be used to static render pages;
- `routes`: Array of routes to render.
- `discoverRoutes`: Whether the builder should statically discover routes.
- `routesFile`: The path to a file containing routes separated by newlines.
The `cacache` package was only minimally used within the font inlining post-build
processing. The usage has now been replaced with direct filesystem access and key
hashing to cache any font files. This not only lowers the overall dependency count
but also provides a small performance improvement by removing the need to resolve,
load, and evaluate additional JavaScript at build time.
The file searching within the build system (both Webpack and esbuild) now use the
`fast-glob` package for globbing which provides a small performance improvement.
Since the assets option in particular is within the critical path of the buil pipeline,
the performance benefit from the switch will be most prevalent in asset heavy projects.
As an example, the Angular Material documentation site saw the asset discovery time
reduced by over half with the switch. `fast-glob` is also the package used by Vite
which provides additional benefit by ensuring that the Angular CLI behavior matches
that of the newly integrated Vite development server.
When using the esbuild-based browser application builder with the development server, an
underlying Vite server is used. The Vite server currently does not support glob-based entries
for the proxy configuration. They must either be prefix strings or regular expressions. The
Webpack-based development server, however, does support globs. To remove the need to have
different proxy configuration files for the two servers, the entries will now be normalized
to regular expressions when using the Vite server. This allows existing proxy configurations
to work without modification.
This configures polyfills to set up the environment before executing Jest tests. We need to do three things:
1. Set the global `jest` symbol. Jest executing in ESM does not provide the `jest` global and users are expected to import from `@jest/globals` or `import.meta.jest`. Zone.js is not compatible with this yet, so we need to manually define the `jest` global for Zone to read it.
2. Run user polyfills, (typically including `zone.js` and `zone.js/testing`). Zone reads the `jest` global to recognize the environment it is in and patch the relevant functions to load fake async properly. Users can override this part if they are building a Zoneless application or have custom polyfills for other browser functionality.
3. Initalize `TestBed`. This configures the `TestBed` environment so users don't have to manually configure it for each test file.
Ordering is very important for these operations, which complicates the implementation somewhat. `zone.js/testing` does not include an import on `zone.js`, meaning there was no guarnatee the bundler would sort their executions in the correct order. Similarly, `zone.js` does not import anything from Jest, so it is not trivial to inject the `globalThis.jest = import.meta.jest;` line before Zone loads. Even setting polyfills to `[jestGlobal, 'zone.js, 'zone.js/testing', initTestBed]` doesn't work because code splitting rearranges the order of operations in an incompatible way. Instead, these are implemented as distinct entry points in `browser-esbuild` with Jest's `--setupFilesAfterEnv` option executing them in the correct order.
Ideally, we could drop the global initialization altogether once Zone.js knows to look for `import.meta.jest` in an ESM context. Also we might be able to reduce down to a single polyfills entry point if `zone.js/testing` had an import on `zone.js` to apply correct ordering.
For now this just runs ESBuild-er to build test code, Jest is not actually invoked yet.
This uses `glob` to find test files matching the given pattern. I went out of my way to limit `glob` functionality as much as possible in case we change the implementation later.
Previously when using the esbuild-based browser application builder with the new dev server,
resource files referenced via stylesheets may not have been served by the development server.
The development server has now been adjusted to properly prioritize and serve files that were
generated during the build process.
Global stylesheets are also currently considered resource files as well to workaround issues
with development sourcemaps within the development server itself. Global stylesheets are already
fully processed by the build system prior to being passed to the development server.
When using the esbuild-based browser application builder and its newly supported development
server, the SSL related `dev-server` builder options can now be used. These include the existing
`ssl`, `sslCert`, and `sslKey` options. Additionally, if no certificate and key are provided
the `@vitejs/plugin-basic-ssl` plugin will be used to provide an auto-generated one.
When using the experimental esbuild-based browser application builder, the preexisting `dev-server` builder
can now be used to execute the `ng serve` command with an esbuild bundled application. The `dev-server` builder
provides an alternate development server that will execute the `browser-esbuild` builder to build the application
and then serve the output files within a development server with live reload capabilities.
This is an initial integration of the development server. It is not yet fully optimized and all features
may not yet be supported. SSL, in particular, does not yet work.
If already using the esbuild-based builder, no additional changes to the Angular configuration are required.
The `dev-server` builder will automatically detect the application builder and use the relevent development
server implementation. As the esbuild-based browser application builders is currently experimental, using
the development server in this mode is also considered experimental.
The `zone.js` package is currently built into a module structure form that resembles
UMD-like output. This causes the CommonJS checker within the experimental esbuild-based
browser application builder to issue a warning for `zone.js` usage. Until the packaging
of `zone.js` is updated to become fully ESM, the `zone.js` package is automatically allowed
when performing the CommonJS module check.
Within the build optimizer's static member optimization pass, a class that is directly
default exported must be split into two statements: the class declaration and the
default export. This is because the pass can wrap classes in a pure annotated IIFE which
results in a variable declaration replacement and variable declarations can not be directly
default exported. Previously, the pass did this splitting manually but this was causing
later babel plugins to fail. In addition to updating the AST in this case, scoping information
also needed to be updated. To support this, a babel helper package is now used that handles
the details of the statement split operation.
When using the experimental esbuild-based browser application builder, stylesheets written in the Less
stylesheet language can now be used throughout an application. The support allows Less stylesheets to
be used in all locations where CSS and/or Sass can be used. This includes global stylesheets and both
inline and external component styles. When using inline component styles, the `inlineLanguageStyle`
build option must be set to `less`.
Currently, import resolution within a Less stylesheet is limited to default Less behavior which does not
include full node package resolution. Full resolution behavior will be added in a future change.
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.
`minimatch` was unused within the `@angular-devkit/build-angular` package.
It is still used in a repository level development script and has been kept
in the root `package.json`.
When using the experimental esbuild-based browser application builder with Sass and sourcemaps, the final
sourcemap for an input Sass stylesheet will now contain the original content for any `url` functions that
were rebased to support bundling. This required generating internal intermediate source maps for each imported
stylesheet that was modified with rebased URLs and then merging these intermediate source maps with the
final Sass generated source map. This process only occurs when stylesheet sourcemaps are enabled.
The `postcss-imports` package was previously used to support `@import` within CSS files. Unfortunately,
the package does not account for `package.json` exports fields. This prevents imports defined within that
field from working when used within a build. The `css-loader` package does provide this functionality and
is now used to provide support for CSS `@import` instead of `postcss-imports`. This change does not affect
preprocessors that provide their own import behavior.
The experimental esbuild-based browser application builder now contains initial support for
watching input files and rebuilding the application via the `--watch` option. This initial
implemention is not yet optimized for incremental rebuilds and will perform a full rebuild
upon detection of a change. Incremental rebuild support will be added in followup changes
and will significantly improve the rebuild speed.
The `chokidar` npm package is used to perform the file watching which allows for native file-
system event based watching. Polling is also support via the `--poll` option for environments
that require it.
The usage of Stylus in the CLI is minimal and this package never reached version 1.
BREAKING CHANGE:
Deprecated support for Stylus has been removed. The Stylus package has never reached a stable version and its usage in the Angular CLI is minimal. It's recommended to migrate to another CSS preprocessor that the Angular CLI supports.
This dependency is only used to valid that node packages are resolved correctly.
With this change we mock the structure of font-awesome to avoid having to install it.
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.
This commit add a new `externalDependencies` option to the experimental browser builder.
Dependencies listed in this option will not be included in the final bundle, instead the user would need to provide them at runtime using import maps or another method.
Closes#23322
Since Angular 8, the CLI has transformed decorator metadata to a form that can be used by the Angular dependency injector without the TDZ limitations of Typescript's decorator metadata emit feature.
As a result, a JIT application compiled with the CLI no longer requires the reflect metadata polyfill that was provided by `core-js`.
This polyfill was also the last remaining usage of the `core-js` package within `@angular-devkit/build-angular` which allows the `core-js` package to also be removed.
Refs: https://github.com/angular/angular-cli/pull/14473 & https://github.com/angular/angular/pull/37382
BREAKING CHANGE: Reflect metadata polyfill is no longer automatically provided in JIT mode
Reflect metadata support is not required by Angular in JIT applications compiled by the CLI.
Applications built in AOT mode did not and will continue to not provide the polyfill.
For the majority of applications, the reflect metadata polyfill removal should have no effect.
However, if an application uses JIT mode and also uses the previously polyfilled reflect metadata JavaScript APIs, the polyfill will need to be manually added to the application after updating.
To replicate the previous behavior, the `core-js` package should be manually installed and the `import 'core-js/proposals/reflect-metadata';` statement should be added to the application's `polyfills.ts` file.
BREAKING CHANGE:
The deprecated `showCircularDependencies` browser and server builder option has been removed. The recommended method to detect circular dependencies in project code is to use either a lint rule or other external tools.
The `proxyConfig` option for the `dev-server` builder now supports JSON files containing comments and trailing commas.
Several additional tests regarding the use of ESM and CommonJS JavaScript configuration files were also added to reduce the likelihood of future regressions.
Closes: #21862
