With this change when SSG is enabled a `prerendered-routes.json` file is emitted that contains all the prerendered routes.
This is useful for Cloud providers and other server engines to have server rules to serve these files as static.
When using an esbuild-based builder (`application` or `browser-esbuild`) with the development server,
a build that fails due to an TypeScript, Angular, or bundling error will now skip all output file result
processing. This avoids unnecessary work since an update of the client code will not take place. This
also allows for an error overlay to be displayed showing the first error available. The full list of
errors will still be shown in the console used to execute the `ng serve` command. Fixing the error will
automatically clear the error overlay but if there were multiple errors the next unfixed error will be
shown instead.
Previously, the application builder relied on TypeScript to detect affected component files via changes
to the internal template type check code. However, not all AOT compiler generated template errors will cause
the template type check code to be changed. Block syntax errors are one example. To ensure that component
diagnostics are recalculated when required, the component file will now always be considered affected when
a used template file is changed.
When using the application builder with Tailwind directives not in a directly referenced
Sass stylesheet, the Tailwind process was previously skipped. To avoid this problem, the
Tailwind keyword checks are now performed on the result of any stylesheet language processing
which will contain all the used stylesheet content.
When using the application builder with a Web Worker in watch mode, A change to the
Web Worker code will now invalidate the referencing source file to ensure that all changes
are captured and the new output file for the Web Worker is correctly injected into the
referencing output file. Previously, the Web Worker output file may have changed but the
reference may not have been updated causing an old instance of the Web worker code to be
used in watch mode.
Component style bundling when using the application builder will now only generate incremental contexts
when in watch mode. During non-watch build, this incremental context information is not needed and
unnecessarily increases memory usage during a build.
With this commit when running a build with sourcemaps enabled we enable Node.js Sourcemap support for stack traces.
See: https://nodejs.org/dist/latest/docs/api/cli.html#--enable-source-maps for more information about this feature.
Before
```
ERROR ReferenceError: window is not defined
at new _AppComponent (file:///chunk-HFZN2HE2.mjs:41631:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (file:///chunk-HFZN2HE2.mjs:41635:12)
at getNodeInjectable (file:///chunk-HFZN2HE2.mjs:6104:38)
at createRootComponent (file:///chunk-HFZN2HE2.mjs:10446:31)
at ComponentFactory.create (file:///chunk-HFZN2HE2.mjs:10348:19)
at _ApplicationRef.bootstrap (file:///chunk-HFZN2HE2.mjs:13247:40)
at file:///chunk-HFZN2HE2.mjs:12938:20
at _ZoneDelegate.invoke (file:///chunk-HFZN2HE2.mjs:320:158)
at Object.onInvoke (file:///chunk-HFZN2HE2.mjs:8562:25)
at _ZoneDelegate.invoke (file:///chunk-HFZN2HE2.mjs:320:46)
```
Now
```
ERROR ReferenceError: window is not defined
at constructor (/usr/xxxx/src/app/app.component.ts:16:17)
at NodeInjectorFactory.AppComponent_Factory (/usr/xxxx/src/app/app.component.ts:17:3)
at getNodeInjectable (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:4166:38)
at createRootComponent (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:14064:31)
at ComponentFactory.create (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:13931:19)
at _ApplicationRef.bootstrap (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:30650:40)
at <anonymous> (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:30163:20)
at _ZoneDelegate.invoke (/usr/xxxx/node_modules/zone.js/fesm2015/zone-node.js:344:158)
at Object.onInvoke (/usr/xxxx/node_modules/@angular/core/fesm2022/core.mjs:10964:25)
at _ZoneDelegate.invoke (/usr/xxxx/node_modules/zone.js/fesm2015/zone-node.js:344:46)
```
Closes#26013
When using the application builder to create server builds for SSR and/or prerendering with localization
enabled, the locale data for each enabled locale is now properly included in the server output files.
While browser builds contain this data in the polyfills output file, the server builds do not contain a
polyfill output file, as a result, the locale data is added to the main server code instead. This is also
the case for other polyfill-like code including zone.js.
Any provided or required polyfills (the later mainly related to i18n) will now be bundled in a separate
concurrent bundling action. This has several benefits including allowing different bundling options
for the polyfills and minimizing rebundling of polyfills (which rarely change) in watch/serve mode.
Along with this change, the polyfill bundling options have been adjusted to not externalize packages
when in development server mode. This allows the zone.js globals to be more easily used as well as
minimizing the need for Vite to process a typically unchanging output file.
When using localization with the application builder for a large amount of locales, the number
of files that may need to be written to disk can become large. This may be problematic on certain
operating systems depending on the open file process limits. To avoid approaching the limit, the
number of concurrent writes is now limited to 64.
Within the application builder's template stylesheet processing, internal identifiers are used to track
the incremental bundling status of each inline stylesheet. This identifier now consists of the stylesheet
language, data, and containing file. This ensures that a tracking entry is maintained for each inline
stylesheet and allows for the full cleanup and any incremental bundling resources at the end of the build.
When a Less stylesheet is detected to require the deprecated `javascriptEnabled` Less option, the option
is enabled for the stylesheet and a warning is issued to inform the user of the behavior change. The
Less `javascriptEnabled` option has been deprecated and disabled by default since Less v3 (https://github.com/less/less.js/releases/tag/v3.0.0).
When enabled, the `javascriptEnabled` option allows JavaScript within Less stylesheets to be executed at build time.
Less option reference: https://lesscss.org/usage/#less-options
This provides similar behavior to the default Webpack-based build system. However, the Webpack-based build system
currently unconditionally enables the option.
Similar to the existing Webpack-based `browser` builder, the new `application` builder is also exported
from the `@angular-devkit/build-angular` package for use programmatically. As is the case for the existing
builder JavaScript exports from the package, the new export (`buildApplication`) is also considered experimental
and does not provide the support nor semver guarantees that the builders have when used via `angular.json` configuration.
The usage of the `plugins` parameter of the `buildApplication` allows adding esbuild compatible plugins to the end
of the plugin list for the main application code bundling. However, usage of the parameter may result in unexpected application
output and/or build failures. Stable and supported methods for build process extension are being evaluated for a future release.
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.
