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.
The development server used with the esbuild-based builders (`application`/`browser-esbuild`) will
now use the recently introduced hash values provided by esbuild in its output files. This removes
the need for each file to be hashed and analyzed on each rebuild during the development server
update analysis.
This commit improves the printed error messages when using Vite with SSR and/or SSG by doing a couple of things.
- Enabling resolving and loading of sourcemap in Node.js by using `process.setSourceMapsEnabled`. See https://nodejs.org/api/process.html#processsetsourcemapsenabledval
- Amends Vite's `ssrTransform` method to remap the sourcemaps and inlines them.
- Enables `__zone_symbol__DISABLE_WRAPPING_UNCAUGHT_PROMISE_REJECTION` Zone.js flag to output cleaner stacktraces.
To enable, the above mentioned zone.js flag we had to create a server polyfill bundle as otherwise in some cases, zone.js would have been split and loaded before the flag.
**Before**
```
ERROR ReferenceError: window is not defined
at new _AppComponent (/main.server.mjs:36:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (/main.server.mjs:42:12)
at getNodeInjectable (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:4277:44)
at createRootComponent (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14399:35)
at ComponentFactory.create (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14263:25)
at ApplicationRef.bootstrap (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:31122:42)
at file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:30644:32
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:368:26)
at Object.onInvoke (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11202:33)
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:367:52)
ERROR Error: Uncaught (in promise): ReferenceError: window is not defined
ReferenceError: window is not defined
at new _AppComponent (/main.server.mjs:36:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (/main.server.mjs:42:12)
at getNodeInjectable (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:4277:44)
at createRootComponent (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14399:35)
at ComponentFactory.create (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14263:25)
at ApplicationRef.bootstrap (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:31122:42)
at file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:30644:32
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:368:26)
at Object.onInvoke (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11202:33)
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:367:52)
at resolvePromise (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:1124:31)
at /usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:1195:17
at _ZoneDelegate.invokeTask (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:402:31)
at AsyncStackTaggingZoneSpec.onInvokeTask (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:10879:28)
at _ZoneDelegate.invokeTask (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:401:60)
at Object.onInvokeTask (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11189:33)
at _ZoneDelegate.invokeTask (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:401:60)
at Zone.runTask (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:173:47)
at drainMicroTaskQueue (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:581:35) {
rejection: ReferenceError: window is not defined
at new _AppComponent (/main.server.mjs:36:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (/main.server.mjs:42:12)
at getNodeInjectable (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:4277:44)
at createRootComponent (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14399:35)
at ComponentFactory.create (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14263:25)
at ApplicationRef.bootstrap (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:31122:42)
at file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:30644:32
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:368:26)
at Object.onInvoke (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11202:33)
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:367:52),
promise: ZoneAwarePromise [Promise] {
__zone_symbol__state: 0,
__zone_symbol__value: ReferenceError: window is not defined
at new _AppComponent (/main.server.mjs:36:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (/main.server.mjs:42:12)
at getNodeInjectable (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:4277:44)
at createRootComponent (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14399:35)
at ComponentFactory.create (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14263:25)
at ApplicationRef.bootstrap (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:31122:42)
at file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:30644:32
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:368:26)
at Object.onInvoke (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11202:33)
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:367:52)
},
zone: <ref *1> Zone {
_parent: Zone {
_parent: [Zone],
_name: 'asyncStackTagging for Angular',
_properties: {},
_zoneDelegate: [_ZoneDelegate]
},
_name: 'angular',
_properties: { isAngularZone: true },
_zoneDelegate: <ref *2> _ZoneDelegate {
_taskCounts: [Object],
zone: [Circular *1],
_parentDelegate: [_ZoneDelegate],
_forkZS: null,
_forkDlgt: null,
_forkCurrZone: null,
_interceptZS: null,
_interceptDlgt: null,
_interceptCurrZone: null,
_invokeZS: [Object],
_invokeDlgt: [_ZoneDelegate],
_invokeCurrZone: [Circular *1],
_handleErrorZS: [Object],
_handleErrorDlgt: [_ZoneDelegate],
_handleErrorCurrZone: [Circular *1],
_scheduleTaskZS: [Object],
_scheduleTaskDlgt: [_ZoneDelegate],
8:23:50 AM [vite] Internal server error: window is not defined
at new _AppComponent (/main.server.mjs:36:19)
at NodeInjectorFactory.AppComponent_Factory [as factory] (/main.server.mjs:42:12)
at getNodeInjectable (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:4277:44)
at createRootComponent (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14399:35)
at ComponentFactory.create (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:14263:25)
at ApplicationRef.bootstrap (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:31122:42)
at file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:30644:32
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:368:26)
at Object.onInvoke (file:///usr/local/xxx/cli-reproduction/test-ssr-/node_modules/@angular/core/fesm2022/core.mjs:11202:33)
at _ZoneDelegate.invoke (/usr/local/xxx/cli-reproduction/test-ssr-/node_modules/zone.js/fesm2015/zone-node.js:367:52)
```
**After**
```
ERROR ReferenceError: window is not defined
at console (/src/app/app.component.ts:17:3)
at NodeInjectorFactory.AppComponent_Factory (/src/app/app.component.ts:12:26)
at getNodeInjectable (/usr/local/xxx/git/packages/core/src/render3/di.ts:659:38)
at createRootComponent (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:464:31)
at ComponentFactory.create (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:288:19)
at ApplicationRef.bootstrap (/usr/local/xxx/git/packages/core/src/application_ref.ts:1017:38)
at <anonymous> (/usr/local/xxx/git/packages/core/src/application_ref.ts:287:20)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
at Object.onInvoke (/usr/local/xxx/git/packages/core/src/zone/ng_zone.ts:443:29)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
ERROR ReferenceError: window is not defined
at console (/src/app/app.component.ts:17:3)
at NodeInjectorFactory.AppComponent_Factory (/src/app/app.component.ts:12:26)
at getNodeInjectable (/usr/local/xxx/git/packages/core/src/render3/di.ts:659:38)
at createRootComponent (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:464:31)
at ComponentFactory.create (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:288:19)
at ApplicationRef.bootstrap (/usr/local/xxx/git/packages/core/src/application_ref.ts:1017:38)
at <anonymous> (/usr/local/xxx/git/packages/core/src/application_ref.ts:287:20)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
at Object.onInvoke (/usr/local/xxx/git/packages/core/src/zone/ng_zone.ts:443:29)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
8:13:37 AM [vite] Internal server error: window is not defined
at console (/src/app/app.component.ts:17:3)
at NodeInjectorFactory.AppComponent_Factory (/src/app/app.component.ts:12:26)
at getNodeInjectable (/usr/local/xxx/git/packages/core/src/render3/di.ts:659:38)
at createRootComponent (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:464:31)
at ComponentFactory.create (/usr/local/xxx/git/packages/core/src/render3/component_ref.ts:288:19)
at ApplicationRef.bootstrap (/usr/local/xxx/git/packages/core/src/application_ref.ts:1017:38)
at <anonymous> (/usr/local/xxx/git/packages/core/src/application_ref.ts:287:20)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
at Object.onInvoke (/usr/local/xxx/git/packages/core/src/zone/ng_zone.ts:443:29)
at _ZoneDelegate.invoke (/node_modules/zone.js/fesm2015/zone-node.js:370:40)
```
**Note:** in the above case the error is printed 3x, this will be addressed in the future.
In the Vite-based development server, an error overlay is requested if a build encounters
an error. This error is then cleared when the error is corrected. However, the flag indicating
that the error was cleared was not previously reset. This resulted in additional empty update
commands being sent to the Vite client. While this has no visual effect, it is unneeded additional
processing.
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.
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.
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`.
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
Prior to this change, async/await in external packages were not being correctly downlevelled when using vite dev-server with cache enabled.
Closes#25985
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 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 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.
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.
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.
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.
This commit updates the Vite based dev-server to send updates for global styles using the HMR update instead of a full page reload when the the dev-server builder `hmr` option to be enabled.
The underlying development server (Vite) for the application build system updated
its static file serving dependencies which resulted in the `@fs` special file URLs
supported by Vite to have a different format. Previously, the paths were encoded
using `encodeURIComponent` but are now use `encodeURI`. The development server
integration with Vite will now use the matching encoding to allow build defined
assets to be correctly served.
When using prebundling with the Vite-based development server, the Angular linker will now
correctly emit JIT module scope information. This information is required in JIT mode for
NgModules to successfully be used in an application.
The `entries` option should be used instead of the `includes` option to disable the
file entry based discovery for Vite's prebundling. This discovery is unneeded due
to the built application files existing only in memory.
When using the Webpack-based browser application builder with the development server, the
proxy configuration can be in an array form when using the `proxyConfig` option. This is unfortunately
not natively supported by the Vite development server used when building with the esbuild-based
browser application builder. However, the array form can be transformed into the object form.
This transformation allows for the array form of the proxy configuration to be used by both
development server implementations.
When using the development server with the esbuild-based browser application builder, the underlying
Vite server will now prebundle packages present in an application. During the prebundling process,
the Angular linker will also be invoked to ensure that APF packages are processed for AOT usage.
The Vite prebundling also provides automatic persistent caching of processed packages. This allows
reuse of processed packages across `ng serve` invocations. To support the use of prebundling at the
development server level, all packages are considered external from the build level. The first time
a package is used within an application there may be a short delay upon accessing the page as the
package is processed. Due to the persistent nature of the prebundling, the `ng cache` command is used
to control the use of the feature. Please note, however, disabling the cache will also disable TypeScript
incremental compilation if not otherwise specifically disabled.
The file searching within the build system (both Webpack and esbuild) now use the
`fast-glob` package for globbing which provides a small performance improvement.
Since the assets option in particular is within the critical path of the buil pipeline,
the performance benefit from the switch will be most prevalent in asset heavy projects.
As an example, the Angular Material documentation site saw the asset discovery time
reduced by over half with the switch. `fast-glob` is also the package used by Vite
which provides additional benefit by ensuring that the Angular CLI behavior matches
that of the newly integrated Vite development server.
When using the esbuild-based browser application builder with the development server, configured
application assets are served directly from disk. The URLs passed to Vite are now percent encoded
to properly handle asset paths that may contain unsupported URL characters.
When using the esbuild-based browser application builder with the Vite-based development
server on Windows, source asset paths were previously not normalized prior to being included
in request URLs. This could result in invalid asset request URLs due to invalid path
segment separators.
To allow lower overhead trial of the developer preview of the esbuild-based builder system,
the development server now has an option to force the usage of the esbuild-based
build system while still retaining the default Webpack-based build system for the
`build` command. The `forceEsbuild`/`--force-esbuild` option can be added to the
`angular.json` options for the `serve` target or used on the command line, respectively.
The `browser-esbuild` builder will be used to build the application using the options
specified by the server configuration's `browserTarget` option. Unsupported build options
will be ignored. If using a third-party builder, a warning will be issued but the build
will still be attempted. Third-party builder usage in this context is considered
unsupported and may result in unexpected behavior or build failures.
When using the esbuild-based browser application builder with the development server, the incoming
URL for the index HTML may contain search parameters or other URL elements that can cause the index
HTML content to not be found or processed incorrected by the development server. These elements are
cleaned prior to comparison and the original URL is not longer passed to Vite to avoid unneeded
Vite specific processing of the content.
When using the esbuild-based browser application builder with the development server, an
underlying Vite server is used. The Vite server currently does not support glob-based entries
for the proxy configuration. They must either be prefix strings or regular expressions. The
Webpack-based development server, however, does support globs. To remove the need to have
different proxy configuration files for the two servers, the entries will now be normalized
to regular expressions when using the Vite server. This allows existing proxy configurations
to work without modification.
When using the esbuild-based browser application builder with the development server,
the `baseHref` build option will now be properly propagated to the underlying Vite
server.
Vite inlines the source map as part of content (ba62be40b4/packages/vite/src/node/server/send.ts (L59-L63)) with no option to disable this behaviour. While this is improves performances when Vite is used without prebundling. When using prebundling this is causes an overhead as the response can grow drastically, in some cases over 50mb.
The change detection logic for the output files is now moved to a separate function
to reduce the code line count for the main dev-server function.
Also changed the setup function for the vite server to return the actual configuration
to allow for better reuse and testability.
When using the esbuild-based browser application builder with the dev-server builder, sourcemap
URL comments were unintentionally doubled due to vite adding an additional inline sourcemap comment
when processing the JavaScript files for the application. To avoid this, JavaScript files now have
any sourcemap URL comments removed prior to being processed by vite. The sourcemap content is already
passed directly to vite and allows the sourcemaps to be processed and provided to the browser as needed
without the previously existing sourcemap URL comment. The removal is done without modifying the esbuild-
based builder's options to avoid assuming the builder used with the dev-server has sourcemap options that
allow hidden sourcemap generation.
Previously when using the esbuild-based browser application builder with the new dev server,
resource files referenced via stylesheets may not have been served by the development server.
The development server has now been adjusted to properly prioritize and serve files that were
generated during the build process.
Global stylesheets are also currently considered resource files as well to workaround issues
with development sourcemaps within the development server itself. Global stylesheets are already
fully processed by the build system prior to being passed to the development server.
When using the esbuild-based browser application builder and its newly supported development
server, the SSL related `dev-server` builder options can now be used. These include the existing
`ssl`, `sslCert`, and `sslKey` options. Additionally, if no certificate and key are provided
the `@vitejs/plugin-basic-ssl` plugin will be used to provide an auto-generated one.
