The `buildTarget` options for both the `dev-server` and `extract-i8n` builders
now have default values that reflect the recommended and new project generated
values. The defaults are as follows where `<current-project>` is the name of the project
where the `dev-server` or `extract-i18n` builder target is located:
* `dev-server` --> `<current-project>:build:development`
* `extract-i18n` --> `<current-project>:build`
Additionally, abbreviated target specifiers are now supported for these
options. This allows target specifiers such as `::production` which would expand
to `<current-project>:build:production` for either builder.
Abbreviated target specifiers are only supported for the `buildTarget` option in
the `dev-server` and `extract-i18n` builders.
When using the experimental programmatic API for the development server, the choice of builder used
to execute the actual underlying build can now be chosen via a selector function extension option.
The returned string value must be one of the first-party esbuild-based builders for the Vite-based
development server to be used. All other returned values will cause the Webpack-based development
server to be used. The Vite-based development server currently requires one of those builders to
be used (either `@angular-devkit/build-angular:application` or `@angular-devkit/build-angular:browser-esbuild`).
The previously unused `reuseResults` option for the JavaScript transformer used by the
`application` builder has been removed and replaced with an optional cache option. This
option is currently unused by will allow the caching of JavaScript transformations including
the Angular linker.
Experimental programmatically added build extensions are now passed to the internal application builder
when used with the development server. Previously, the plugins were not passed in a manner that would
allow them to be used if the `application` builder was selected as the builder for dev server usage.
This improvement harmonizes the proxy configuration loading mechanisms between the dev-server and ssr-dev-server. Previously, these servers used different methods for loading the proxy configuration, leading to inconsistencies. Notably, the ssr-dev-server was limited to loading configurations only in JSON format. This change enables the ssr-dev-server to support various configuration formats, aligning it with the dev-server's capabilities and improving overall developer experience.
This commit fixes an issue were when using a `baseHref` with trailing slash, vite dev-server would have been only accessible via a URL with a trailing slash. As vite would redirect to an error page similar to the below;
```
The server is configured with a public base URL of /myapp/ - did you mean to visit [/myapp/](http://localhost:4200/myapp/) instead?
```
Closes: #26618
To ensure that the `forceEsbuild` development server option chooses the correct underlying build implementation when
the project contains the `browser` builder within the build target, an explicit check and conversion of the builder
name is now performed during the initialization phase of the development server builder.
Vite appears to consider a port value of `0` as a falsy value and use the default Vite port of
`5173` when zero is used as a value for the development server port option. To workaround this
issue, the port checker code now explicitly handles the zero value case and determines a random
port as would be done automatically by the Webpack-based development server.
The Vite-based development server uses an allow list to permit access to configured assets. This list
is checked internally to Vite by using its normalized path form. To ensure that assets provided by the
build are checked correctly on all platforms, the asset list is now normalized with Vite's path
normalization prior to being used.
When using the `application` or `browser-esbuild` builders with the `dev-server`, interactive key
shortcuts are now available to use while the server is active. Once the build has successfully completed
and the development server has initialized, typing a single letter key followed by enter will execute
the associated action. These actions include forcing a browser full reload, clearing the console, or
quitting. More actions may be added in the future.
The following actions are currently available:
```
press r + enter to force reload browser
press u + enter to show server url
press o + enter to open in browser
press c + enter to clear console
press q + enter to quit
```
The `h` action is also available which will display the above list at runtime.
To minimize ambiguity, the update related log messages for the development server now consistently
indicate that the page reload, HMR update, or otherwise has actually been sent to any connected clients.
The Vite-based development server restricts filesystem access by default. However, assets
configured by the build option `assets` are intended to be accessible by the application at
runtime. To ensure that these files are accessible, the allow list will now explicitly include
all configured assets found during the build.
With the Vite-based development server, the build pipeline itself watches for files
and rebuilds the relevant parts of the application as needed. The Vite file watching
is unneeded and was previously setup to ignore all files. This worked but was not
ideal as chokidar was still initialized inside Vite. However, Vite now supports fully
disabling the file watching by passing `null` for the Vite watch option value.
The application builder logic will now be used when the Vite-based development server is used with a
custom builder. This aligns with the programmatic export of application builder. This allows consistent
behavior for custom builders that use both the application builder and dev server builder APIs.
When using the `application` builder, a new `loader` option is now available for use.
The option allows a project to define the type of loader to use with a specified file extension.
A file with the defined extension can then used within the application code via an import statement
or dynamic import expression, for instance.
The available loaders that can be used are:
* `text` - inlines the content as a string
* `binary` - inlines the content as a Uint8Array
* `file` - emits the file and provides the runtime location of the file
* `empty` - considers the content to be empty and will not include it in bundles
The loader option is an object-based option with the keys used to define the file extension and the values used
to define the loader type.
An example to inline the content of SVG files into the bundled application would be as follows:
```
loader: {
".svg": "text"
}
```
An SVG file can then be imported:
```
import contents from './some-file.svg';
```
Additionally, TypeScript needs to be aware of the module type for the import to prevent type-checking
errors during the build. This can be accomplished with an additional type definition file within the
application source code (`src/types.d.ts`, for example) with the following or similar content:
```
declare module "*.svg" {
const content: string;
export default content;
}
```
The default project configuration is already setup to use any type definition files present in the project
source directories. If the TypeScript configuration for the project has been altered, the tsconfig may
need to be adjusted to reference this newly added type definition file.
Prior to this commit, the pre-bundling of dependencies was being invalidated for each build. This is because vite uses parts of the config among other things to generate a hash. In our case the config was not always consistent for the same project between different builds.
The main 2 problems areas were:
- Random `root` path
- `include` and `exclude` arrays were not always in the same order.
It appears that Vite currently, has a number of limitation/bugs when using `optimizeDeps` for SSR bundles.
Currently this causes a number of issues:
- Deps are re-optimized everytime the server is started.
- Added deps after a rebuild are not optimized.
- Breaks RxJs (Unless it is added as external). See: #26235
We should follow up with Vite and try to get this solved as this would be a nice feature to use.
Closes#26235 and #26234
Currently, externalMetadata arrays get appended the same items over and over again on every rebuild. This commit cleans the array before it appending the new values.
The `JavaScriptTransformer` class that is responsible for Angular linking and several build optimization
transformations can now be configured to track and reuse previous and pending transformation requests.
This allows for cases where multiple consumers of the class will not cause repeat transformation actions.
Pending results will be stored if the constructor option `reuseResults` is enabled. If two transformation
requests are issued for the same file, the same underlying result will be provided to each. This behavior
currently only applies to file transformation requests.
Vite will only start dependency optimization of SSR modules when the first request comes in.
In some cases, this causes a long waiting time. To mitigate this, we call `ssrLoadModule` to initiate this process before the first request.
This fixes the following warnings
```
Cannot optimize dependency: url, present in 'ssr.optimizeDeps.include'
Cannot optimize dependency: path, present in 'ssr.optimizeDeps.include'
```
This commit splits the retrieval of external dependencies into two. Server imports and browser imports. This is so that we avoid vite from optimizing server or browser only dependencies twice.
This also fixes an issue were in some cases Vite would issue a warning like `Cannot optimize dependency: path, present in 'optimizeDeps.include'`. This was caused because of server only dependencies ended up trying to be optimized for a browser build.
When using the experimental programmatic API for the development server with an esbuild-based
builder (`application`/`browser-esbuild`), express compatible middleware can now be added.
Also, the index HTML transformer that previously only worked with the Webpack-based development
server is also now enabled.
However, usage of these options may result in unexpected application output and/or build failures.
They are also not officially supported and SemVer guarantees are not present.
Stable and supported methods for build process extension are being evaluated for a future release.
The commit introduces dependencies prebundling and optimisation for SSR dependencies. This is primarily needed for Angular linking and async/await downlevelling. To enable this, we need to use the undocumented `optimizeDeps` setting under the `ssr` option. This is because, the top level `optimizeDeps` vite config option only controls browser dependencies.
For the above mentioned option to take effect and transform node packages, we also need to use `noExternal` and use a catch all `RegExp`. Note: setting this option to `true` has a different effect from a catch all `RegExp`, as the former will cause the `external` option to be ignored.
Additionally together with `externalMetadata.explicit` we add Node.js build-ins as `external`.
Closes: #26192
The protractor E2E builder relies on a development server `baseUrl` result property to determine the address
to connect when testing the application. The Vite-based development server now also provides this
property. While the protractor builder is considered deprecated, it is still used in CLI E2E tests.
The Vite-based development server that is used with the esbuild-based builders (`application`/`browser-esbuild`)
will show an error overlay when the application build encounters an error. This overlay previously provided a
suggestion to edit the `vite.config.js` configuration file to disable the error overlay. Since Vite usage is
encapsulated within the Angular CLI, this suggestion is unactionable and may lead to user confusion due to
no Vite configuration file being present within the project nor would creating one have an effect on the build
process.
When using the application builder with the development server, Web Worker URLs previously may
have been incorrectly resolved. This caused Vite to consider the Web Worker URLs as outside
the project root and generate a special file system URL. While this worked on Mac/Linux, it
would fail on Windows. Since Vite does not appear to support resolve plugins for Web Workers,
the virtual project root for the in-memory build has now been adjusted to allow the referencing
file to have a path that resolves the Web Worker URL to a project relative location.
`ng serve` might fail with: `Cannot read properties of undefined (reading 'explicit')` because `result.externalMetadata` is optional.
This commit guards the access and should fix the issue related to the fix 9768c184e0
When using the Vite-based development server combined with the `externalDependencies` option, Vite
will no longer attempt to resolve the explicitly marked externals.
This is still not ideal since it vite will still transform the import specifier to `/@id/${source}`
but is currently closer to a raw external than a resolved file path. Further investigation with
a possible feature request for Vite may be needed to achieve the desired outcome of an unresolved
and untransformed external import specifier.
When using the Vite-based development server, the application build step already contains the
list of known packages that would need to be prebundled. This information can be passed to Vite
directly to avoid Vite needing to perform discovery on every output file that will be requested.
This also avoids the Vite server behavior where Vite forces a reload of the page when it discovers
a new dependency. This behavior can result in lost state during lazy loading of a route.
