Protractor is no longer deprecated, it's already end-of-life. I didn't commit to a specific version because plans always fluctuate, but it is eligible to be removed in any future Angular major version.
This is to better match the nature of the application builder where the target can be both browser and server.
DEPRECATED: The `browserTarget` in the dev-server and extract-i18n builders have been deprecated in favor of `buildTarget`.
The `browser-esbuild` builder now provides support for using the `deployUrl` option when building
applications. This option is still considered deprecated which is the same status as with the
Webpack-based `browser` application builder. This option is only available with the `browser-esbuild`
builder and not other esbuild-based builders. The `browser-esbuild` builder is primarily intended
to be used as a compatibility builder with the `browser` builder that requires only minimal changes
to use.
When using the esbuild-based builders (`application`/`browser-esbuild`), the localize polyfill and the locale specifier
for the configured source locale will now be injected into the application when available and the application is not
configured to inline translations (`localize` option disabled or otherwise not used). This is useful for when developing
a localized application with the development server or when the application is not translated but has a customized source
locale.
When normalizing the proxy configuration for the Vite-based development server, the `pathRewrite` logic
will now be skipped if the proxy entry is not an object and therefore invalid. This situation can occur
if the proxy configuration JSON contains invalid properties.
Closes#25978
This commit improves the logic to block and share a TypeScript results across multiple esbuild instances (browser and server builds) which fixes an issue that previously during rebuilds in some cases did not block the build correctly.
Prior to this change, async/await in external packages were not being correctly downlevelled when using vite dev-server with cache enabled.
Closes#25985
With the output path directory structure updates in place, the localize support for SSR has
now been enabled. This allows for the `application` builder to produce both browser and server
output that is localized based on the i18n configuration for the project.
When using the esbuild-based builders (`esbuild-browser`/`application`) in watch mode (including `ng serve`),
component stylesheets will now be incrementally rebuilt when needed. This avoids a full build of each
affected component's styles during an application rebuild. Both JIT and AOT mode are supported as well
as both inline and external styles.
The `anyComponentStyle` budget type is now supported when using bundle budgets in the esbuild-
based builders (`browser-esbuild`/`application`). The configuration and behavior are intended
to match that of the Webpack-based builder (`browser`). With this addition, the bundle budget
feature is now at feature parity with the Webpack-based builder.
The implementation of this budget type requires less code than the Webpack implementation due
to the component stylesheet information being present in the application's output metadata. This
removes the need for a custom budget plugin to extract the stylesheet size information during the build.
The bundle budget functionality (`budgets` option) is not available when using the esbuild-based
builders (`browser-esbuild`/`application`). The existing option format from the Webpack-based builder can
continue to be used. All budget types except `anyComponentStyle` are implemented. Any usage of the
`anyComponentStyle` type will be ignored when calculating budget failures. This type will be implemented
in a future change.
The previous Web Worker bundling code for the esbuild-based builders assumed that the first
output file was the JavaScript code for the worker. While this is typically the case, when
sourcemaps are enabled it may not be. To ensure the code file is used as the replacement path
for the Worker constructor, the output files are now searched for the code file.
This commit updates the application builder to output files in a standardized manner. The builder will output a `browser` directory for all the files that can be accessible by the browser, and a `server` directory that contains the SSR application. Both of these directories are created as children in the configured `outputPath`. Stats and license files will be outputted directly in the configured `outputPath`.
Example of output:
```
3rdpartylicenses.txt
├── browser
│ ├── chunk-2XJVAMHT.js
│ ├── favicon.ico
│ ├── index.html
│ ├── main-6JLMM7WW.js
│ ├── polyfills-4UVFGIFL.js
│ └── styles-5INURTSO.css
└── server
├── chunk-4ZCEIHD4.mjs
├── chunk-PMR7BAU4.mjs
├── chunk-TSP6W7K5.mjs
├── index.server.html
├── main.server.mjs
└── server.mjs
```
This commit removed the hard coded Node.js version in application builder server config and instead passes the Angular CLI supported Node.js versions that are currently stamped using Bazel.
Prior to this change when `baseUrl` was set to non-root or not set polyfills were not correctly resolved. Internally Esbuild uses the `baseUrl` to resolve non relative imports.
Closes: #25341
This adds the support of `namedChunks` for the new `application` builder.
It generates output like the following:
```
Initial Chunk Files | Names | Raw Size | Estimated Transfer Size
chunk-ACXUMF56.js | - | 94.14 kB | 28.25 kB
main-3WP5KDHR.js | main | 71.95 kB | 18.31 kB
polyfills-4UVFGIFL.js | polyfills | 32.85 kB | 10.68 kB
chunk-2XJVAMHT.js | - | 449 bytes | 449 bytes
styles-5INURTSO.css | styles | 0 bytes | 0 bytes
| Initial Total | 199.38 kB | 57.68 kB
Lazy Chunk Files | Names | Raw Size | Estimated Transfer Size
about.component-2PJOS5PM.js | - | 401 bytes | 401 bytes
home.component-25UHFOEY.js | - | 398 bytes | 398 bytes
```
This is really handy to get a glimpse at what a chunk is referring to and be able to analyze it (especially in applications with dozens of chunks).
When using the esbuild-based application build system through the `application` builder, the `localize`
option will now allow inlining project defined localizations when using the app shell, prerendering,
and service worker features. Previously a warning was issued and these features were disabled when the
`localize` option was enabled.
To prevent stale Angular template diagnostics from persisting in watch mode (including `ng serve`), the template
diagnostic cache will now be invalidated based on the set of changed external template files. This ensures that
the Angular AOT compiler will analyze the template again during the rebuild and clear any fixed errors.
To better capture file changes after the initial build for the esbuild-based builders in a programmatic usage,
the file watching initialization has been moved to before the first build results are yielded. This allows tests
that execute code to change files with improved accuracy of the watch mode triggering. The application builder
now also supports aborting the watch mode programmatically. This allows tests to gracefully stop the watch mode
and more fully cleanup the test at completion.
This commit clean ups the compiled components state when the build is being executed in watch mode. This is required as otherwise during development `Component ID generation collision detected` are displayed on the server.
Closes: #25924
This commit disables logging `Angular is running in development mode.` when using SSR with vite dev-server. This to avoid polluting the server console with `Angular is running in development mode.` logs for each page load and reload.
Example:
```
ng s
Initial Chunk Files | Names | Raw Size
main.js | main | 34.31 kB |
polyfills.js | polyfills | 95 bytes |
styles.css | styles | 95 bytes |
| Initial Total | 34.49 kB
Application bundle generation complete. [5.205 seconds]
➜ Local: http://localhost:4200/
Watch mode enabled. Watching for file changes...
Angular is running in development mode.
Angular is running in development mode.
Angular is running in development mode.
Angular is running in development mode.
Angular is running in development mode.
Angular is running in development mode.
```
When using the esbuild-based builders (`application`/`browser`), Web Workers that use the supported
syntax will now be bundled. The bundling process currently uses an additional synchronous internal
esbuild execution. The execution must be synchronous due to the usage within a TypeScript transformer.
TypeScript's compilation process is fully synchronous. The bundling itself currently does not provide
all the features of the Webpack-based builder. The following limitations are present in the current
implementation but will be addressed in upcoming changes:
* Worker code is not type-checked
* Nested workers are not supported
When using the devserver, instead of prerendering every page for every incremental change, we now perform a server rendering on the page during request time. This ensures that incremental build times are faster when prerending is enabled as we avoid rendering of pages that are never viewed.
When using the esbuild-based application build system through either the `application`
or `browser-esbuild` builder, the `localize` option will now allow inlining project
defined localizations. The process to configure and enable the i18n system is the same
as with the Webpack-based `browser` builder. The implementation uses a similar approach
to the `browser` builder in which the application is built once and then post-processed
for each active locale. In addition to inlining translations, the locale identifier is
injected and the locale specific data is added to the applications. Currently, this
implementation adds all the locale specific data to each application during the initial
building. While this may cause a small increase in the polyfills bundle (locale data is
very small in size), it has a benefit of faster builds and a significantly less complicated
build process. Additional size optimizations to the data itself are also being
considered to even further reduce impact. Also, with the eventual shift towards the standard
`Intl` web APIs, the need for the locale data will become obsolete in addition to the build
time code necessary to add it to the application.
While build capabilities are functional, there are several areas which have not yet been
fully implemented but will be in future changes. These include console progress information,
efficient watch support, and app-shell/service worker support.
Some TypeScript files may previously have been emitted twice during builds when using the Angular compiler
esbuild plugin used within the esbuild-based browser application builder. It did not cause any build problems.
However, it may have caused builds to take longer than expected. This was caused by an incorrect comparison of the
transformed source file and the original source file found within the TypeScript program. Comparisons during
emit now compare only original source files which avoids the issue with the emitted files checks.
When using the esbuild-based builders (application/browser-esbuild), Web Workers following the previously
supported syntax as used in the Webpack-based builder will now be discovered. The worker entry points are not
yet bundled or otherwise processed. Currently, a warning will be issued to notify that the worker will not
be present in the built output.
Additional upcoming changes will add the processing and bundling support for the workers.
Web Worker syntax example: `new Worker(new URL('./my-worker-file', import.meta.url), { type: 'module' });`
This commit updates the routes extractor to use the newly exported private `ɵloadChildren` method from the router to executes a `route.loadChildren` callback and return an array of child routes.
See: https://github.com/angular/angular/pull/51818
This commit changes the way that global style updates are applied when using `vite`. When either live-reload or hmr are enabled the styles are replaced in placed (HMR style) without a live-reload.
This fixes an issue were routes could not be discovered automatically in a standalone application.
This is a total overhaul of the route extraction process as instead of using `guess-parser` NPM package, we now use the Angular Router. This enables a number of exciting possibilities for the future which were not possible before.
# How it works?
The application is bootstrapped and through DI injection we get the injector and router config instance and recursively build the routes tree.
The terser build time constant import from the `@angular/compiler-cli` package is no
longer used in the esbuild-based builder. The constants present are already defined
and conditionally added within the build configuration itself. This not only provides
more flexibility but also removes the need to import the package early in the process.
The import is also an expensive import due to it needing TypeScript and being ESM that
needs to be dynamically imported via a function helper to work around current ESM/TypeScript/CommonJS
limitations.
This commit fixes an issue were previously we spawned piscina with `maxThreads` set to `0` which causes it to exit with a non zero error code when there are no routes to prerender.
Now, in the application builder we exit at n earlier stage if there are no routes to prerender.
