The Node.js inspector will now only be imported if SSR is enabled and
the `inspect` option is used. This prevents potential failures when a
custom Node.js binary build is used that has not enabled inspector usage.
While this is not common, loading the inspector on demand is a minimal
change that also avoids loading code that will not be used for the majority
of development server usage.
The application builder now provides structured output types to its internal
consumers. The architect builders themselves and the programmatic API is
not changed. These output result types allow for the development server to
receive additional information regarding the build and update the active
browser appropriately. This functionality is not yet implemented but the
additional result types provide the base infrastructure to enable future
features. The result types also allow for reduced complexity inside other
builders such as i18n extraction and the browser compatibility builder.
The usage is not yet fully optimized and will be refined in future changes.
Replacing the paths to ESM in Vite can cause prebundling to fail in some cases, resulting in errors similar to the following:
```
12:55:12 PM [vite] Error when evaluating SSR module /chunk-CHB4JJIP.mjs:
|- TypeError: Cannot read properties of undefined (reading 'Subject')
at eval (//src/app/shared/snackbar/snackbar.service.ts:2:25)
at async instantiateModule (file:////node_modules/vite/dist/node/chunks/dep-BcXSligG.js:53408:5)
12:55:12 PM [vite] Error when evaluating SSR module /chunk-GQZ5BKXC.mjs:
|- TypeError: Cannot read properties of undefined (reading 'Subject')
at eval (//src/app/shared/snackbar/snackbar.service.ts:2:25)
at async instantiateModule (file:////node_modules/vite/dist/node/chunks/dep-BcXSligG.js:53408:5)
```
Closes: #27907
Previously, ESM file resolution without extensions failed when using Vite, causing issues in module loading. This commit addresses the problem by automatically resolving `.mjs` files, aligning the behavior with the application builder and ensuring consistent module resolution across different build tools.
**NB**: This is a workaround as valid ESM imports should always have an extension.
Closes#27841
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)
This commit introduces an `--inspect` option to the dev-server, enabling debugging of server-side code when using SSR or SSG. This option is equivalent to `node --inspect=[[host:]port]`.
Usage examples:
```
$ ng serve --inspect
$ ng serve --inspect 9999
$ ng serve --inspect localhost:9999
```
Closes: #27773
An informational note will now be shown upon development server startup
to indicate that the raw file sizes shown in the console do not reflect
any of the per-request transformations that may occur within the Vite-based
development server. The raw file size and the size shown within the browser
may differ as a result of these development workflow based transformations.
Rebuilds can now use the optimized external package execute path when using
the `application` builder's `loader` option if only `file` type loaders are
used. The Vite-based development server will now process any `file` type
loader usage for third-party file references which removes the need for the
build itself to handle the loader processing. This change only optimizes
the case where only the `file` loader type is used. If any other loader types
are present, the optimized execution path will not be used. Future further
improvements may allow for all cases to use the optimized rebuild execution
path.
With the `application` builder already within the new `@angular/build` package,
the Vite-based `dev-server` builder is now also contained within this package.
Only the Vite-based aspects of the `dev-server` have been moved and only the
support for the `application` builder. The compatibility builder `browser-esbuild`
is not supported with `@angular/build:dev-server`. The existing `dev-server` builder
found within `@angular-devkit/build-angular` should continue to be used for both the
Webpack-based `browser` builder and the esbuild-based compatibility `browser-esbuild`
builder. To maintain backwards compatibility, the existing `@angular-devkit/build-angular:dev-server`
builder continues to support builders it has previously.
No change to existing applications is required.
