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.
This commit updates the `ng generate application` to use the esbuild `application` builder. This also updates the schematics to support both `browser` and `application` builders.
BREAKING CHANGE: `rootModuleClassName`, `rootModuleFileName` and `main` options have been removed from the public `pwa` and `app-shell` schematics.
An upcoming change in Angular will allow `style` specified as strings, in addition to a new `styleUrl` property. These changes update the JIT resource transform to support the change.
Newer versions of the babel packages allow for removing some types packages as well as some helper
packages. The `@babel/template` package export used within the CLI is accessible from the `@babel/core`
package which allows removal of `@babel/template` as a direct dependency. Also, the `@babel/plugin-proposal-async-generator-functions`
package has been transitioned to `@babel/plugin-transform-async-generator-functions` due to async generators
being merged into the ECMAScript standard. Minor code cleanup based on the type cleanup was also performed
in the build optimizer babel passes.
The development server proxy configuration file for Webpack supports a `pathRewrite` field that is
not directly supported by the underlying Vite development server when using the application or esbuild-
browser builders. To provide equivalent support, especially for JSON file-based proxy configurations,
the `pathRewrite` field is now converted internally to a proxy `rewrite` function.
When using the Vite-based development server and a custom `index` build option (not `index.html`),
the custom index path will now be used as the root of the development server. This mimics the behavior
of the Webpack-based development server.
The JavaScript generated for the published packages is now using ES2022.
This removes additional downleveling of code that was previously necessary
to use newer features.
The minimum Node.js version of 18.13 provides support for the needed features.
While this change does require a patch to `@bazel/concatjs` to allow the target
to be set to `ES2022`, this patch is now already required by the migration of
the universal repository into the CLI repository.
By setting up a single instance of the `JavaTransformer`, the Vite-based development server will now
have a fixed and controllable number of worker threads available to process prebundling requests. This
avoids a potentially large number of initial worker threads when a new application with a large number
of dependencies is first used with the development server. This is particularly beneficial for web
container setups which may not be able to efficiently handle the number of workers.
Updates the logic that elides `setClassMetadata` calls to also elide `setClassMetadataAsync`. The latter will be emitted when the component uses the new `defer` block syntax.
Updates the logic for removing Angular metadata and pure top-level functions to account for arrow-function-based IIFEs. Currently Angular doesn't generate arrow functions, but it's being explored in https://github.com/angular/angular/pull/51637.
The esbuild-based application builder will now access the project level i18n configuration
as well as the builder `localize`, `duplicateTranslationBehavior`, and `missingTranslationBehavior`
options to construct a full, normalized i18n option structure.
These options are not yet used by the builder but they are now available to access as future
work incrementally adds i18n support.
This removes the util function for express, instead the "CommonEngine" is called directly infuture before this package is final we might rename the "CommonEngine" to something else.
