When using the esbuild-based browser application builder, the tsconfig path will now be properly
converted to the realpath when the `preserveSymlinks` option is disabled (the default). This ensures
that TypeScript source files will be properly matched with the bundler's resolved paths when symlinks
are used and the `preserveSymlinks` option is not enabled. This is needed to properly support the use
of bazel with rules_js.
The `outExtension` option allows users to generate `*.mjs` files, which is useful for forcing ESM execution in Node under certain use cases. The option is limited to `*.js` and `*.mjs` files to constrain it to expected values. `*.cjs` could theoretically be useful in some specific situations, but `browser-esbuild` does not support that output format anyways, so it is not included in the type.
I also updated `index.html` generation, which will correctly insert a `<script />` tag with the `*.mjs` extension. I opted to explicitly ban a "non-module" `*.mjs` file, since that would be very counterintuitive and I can't think of a valid use case for it.
For testing use cases, we don't need an `index.html` file in the same capacity as a typical application. The builder already omits an `index.html` page when not set, this just updates the schema to reflect that.
The parameter could be left optional, rather than required but allowing `false`. However doing it this way prevents users from accidentally forgetting to provide an index while still allowing users to explicitly disable index generation. We use `false` instead of `null` so users can write `--no-index` on the command line and get the same behavior, which would not be possible with `null`.
This allows `browser-esbuild` to consume absolute file paths and `entryPoints`. Absolute paths will always output in the root of the output directory with the same basename, since they are not within the workspace root and cannot exist at any guaranteed unique relative path. No attempt is made to check if the absolute path is actually within the workspace root, since this would require a call to `fs.realpath()` and make this logic dependent on the actual file system structure which introduces a lot of complexity we'd rather avoid.
Longer term, the ideal approach is probably to leverage virtual files in some capacity, but this should be sufficient for now.
`main` functionality is left alone, and absolute paths like `/main.ts` are treated as relative to the workspace root. This is to preserve existing functionality and discourage public API usage of file paths outside the workspace.
This makes the `main` parameter optional and allows multiple entry points instead. `main` is still technically required by the schema, since it should almost always be set when invoked by a user. However, it now supports `null` as a value so it can be explicitly omitted.
Longer term, we may choose to remove `main` and fold it into `entryPoints`, but for now we want to keep compatibility with the existing `browser` builder.
Since `entryPoints` is an internal-only options (cannot be set in `angular.json` and isn't exposed in the schema), I made a new `buildEsbuildBrowserInternal()` function which adds the extra private option. This way direct invocations of the builder can provide this extra information without compromising the public API surface defined in the schema.
As is, the `browser` and `browser-esbuild` schemas needed to be identical to check for unsupported properties. This loosens it slightly by casting the `browser-esbuild` schema into the `browser` schema and looking for invalid properties. This makes the module more flexible as the `browser-esbuild` schema evolves _and_ more closely aligns with the actual mistake of users who incorrectly think of `browser-esbuild` as supporting all the options of `browser`, which it does not yet do so.
This commits add a check to display a warning when `preserveWhitespaces` is configured in `tsconfig.server.json`, as potentially this could cause issue with hydration.
Due to a typo in a conditional for the filtering of lazily defined global styles, global
styles were unintentionally always initial if no global scripts were present in the
application.
The code to execute the individual bundling elements of the esbuild-based browser application
builder has been consolidated within a bundler context helper method. This moves the execution
and result merging code into a single location and allows for more flexibility to control which
elements should be executed per build. The global styles and global scripts bundling is now fully
skipped if the options are not present in the build configuration.
The TypeScript and Angular configuration reading (`tsconfig.json`) has now been moved into the
Angular compilation classes (AOT/JIT) directly. This removes compilation specific functionality
from the esbuild plugin and allows the plugin to focus primarily on integration with esbuild.
When using the esbuild-based browser application builder, third-party sourcemaps will now be fully removed
when the `sourcemap` option's `vendor` sub-option is disabled. The `vendor` sub-option is disabled by default
and is only enabled if explicitly enabled within the project's configuration. Sourcemaps are considered
third-party if their referencing code is contained within a `node_modules` directory.
Previously, sourcemap URL comments may have been unintentionally left intact when processing third-party code
via the Babel-based JavaScript transformer. These sourcemap URL comments are now removed correctly when
code is both transformed and return directly when no transformation is required.
When using the esbuild-based browser application builder, only actual initial files will be displayed
in the initial files section. Previously, certain dynamically imported files could unintentionally be
displayed in the stats output table as initial files. This was a display only error and had no effect
on the files added to the index HTML file.
This reverts commit 290e06018d3934cf27a5734a60947dcd7b45fa58.
Release checks don't like being in an RC state and it's not strictly necessary since installing a `-next` package will install `-rc` because it alphabetically follows. This means generating applications with `-next` in the `package.json` will still pull the latest RC releases of Angular packages.
To improve rebuild performance when using Sass stylesheets with the esbuild-based
browser application builder in watch mode, Sass stylesheets that are not affected
by any file changes will now be cached and directly reused. This avoids performing
potentially expensive Sass preprocessing on stylesheets that will not change within
a rebuild.
The output option for the long-form of the assets build option should be a relative path based
from the output path of the application. However, a rooted path was also considered relative
to the output path. To avoid two different ways of representing the path throughout the build
system. The output path is now normalized to a relative path at the beginning of the build
process.
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.
Types and functionality that were used by both the AOT and JIT compilation classes within
the esbuild Angular compiler plugin have been extracted into a common base class that
both now extend. This removes duplicate code from both classes.
Minor directory restructure to better organize the Angular compiler plugin code files.
The remainder of the Angular specific files for the Angular esbuild compiler plugin are now
within the `angular` subdirectory of the esbuild-based browser application builder.
When using the esbuild-based browser application builder, the output path is deleted
prior to performing a build to ensure a clean output with only the built files. The
deletion will now be performed asynchronously using the Node.js promised-based API.
This should provide a small performance improvement for projects with large output
directories.
The package module resolution logic for Sass stylesheets within the esbuild-based browser
application builder has been restructured to limit the need to perform fallback resolution
unless fully required. This allows common cases to avoid unnecessary and expensive resolution
attempts. This provided a roughly 40% improvement in build times for the Angular Material
documentation site.
When using the esbuild-based browser application builder in watch mode, all `node_modules`
directories will now be ignored by the file watcher. Instead all relevant package manifests
and lock files for `npm`, `yarn, and `pnpm` will be watched to detect potential changes
to the project's dependencies. This avoids creating a potentially large amount of filesystem
watchers as the node modules directories can be very large.
When using the esbuild-based browser application builder, the output build file stat table
was incorrectly displaying non-injected global styles and scripts as initial files. These
output files will now be correctly shown as lazy files. Initial files will also now display
their respective name if available. The table entries are now sorted in descending order by
raw file size as was done in the Webpack-based builder.
When using the esbuild-based browser application builder in watch mode, the underlying file
watcher based on chokidar would previously not fully ignore the output path if the path contained
a trailing slash. To workaround this, directory paths based on supplied options are now
normalized to remove any trailing slashes.
When using the esbuild-based browser application builder, all the watch-related code
is now only imported when the watch mode is enabled. This removes the need for Node.js
to resolve and load code that will not be used.
Now that output stat logging for the esbuild-based browser application builder has been
implemented, the previously disabled styles option tests can be enabled.
When using the esbuild-based browser application builder in JIT mode, the Angular
linker will now be skipped. The runtime Angular compiler present in JIT applications
will automatically link any needed code.
When using the esbuild-based browser application builder, the `progress` option which
is enabled by default will now show an activity spinner when building/rebuilding.
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.
The deprecated protractor builder requires that the result object from a development server
provide the port used to access the application if the port is not the default (4200). The
newly introduced esbuild development server will now provide the port when available.
When using the esbuild-based browser application builder with Less stylesheets, import rules
will now attempt to perform node package resolution if the import cannot be found as a relative
path. Built-in Less resolution is performed first to both avoid unnecessary node module resolution
overhead when not needed and also ensure Less relative import semantics continue to be supported.
When using the esbuild-based browser application builder, the `scripts` option will
now provide equivalent functionality to the current default Webpack-based builder.
The option provides full node resolution capabilities which allows both workspace
relative paths and package paths with support for the `script` exports condition.
When using the experimental esbuild-based browser application builder, the preexisting `dev-server` builder
can now be used to execute the `ng serve` command with an esbuild bundled application. The `dev-server` builder
provides an alternate development server that will execute the `browser-esbuild` builder to build the application
and then serve the output files within a development server with live reload capabilities.
This is an initial integration of the development server. It is not yet fully optimized and all features
may not yet be supported. SSL, in particular, does not yet work.
If already using the esbuild-based builder, no additional changes to the Angular configuration are required.
The `dev-server` builder will automatically detect the application builder and use the relevent development
server implementation. As the esbuild-based browser application builders is currently experimental, using
the development server in this mode is also considered experimental.
When using the esbuild-based browser application builder, the Sass worker pool
import is now lazy to prevent unnecessary module loading when Sass is not used
within an application.
When using the esbuild-based browser application builder, the stat output table was incorrectly
displaying source map files and internal component resource files such as inline stylesheets
as initial entries.
Previously when using the esbuild-based browser application builder, an empty inline
component style (`styles: ['']`) would cause the build to fail. This was due to a
bad assertion condition that has now been corrected.
When using the experimental esbuild-based browser application builder, a build
output table will now be displayed upon completion. The table is formatted to
display output file information in a similar way to the default Webpack-based
browser application builder. Estimated transfer size is currently not displayed
but will be added in a future change.
