With this change we replace all usage of `compilation.errors `and `compilation.warnings.push` with `addError` and `addWarning` respectively.
Also, we update the helpers in build-angular to use `WebpackError` from the current compilation to avoid mismatching instances.
With this change we reduce the reliance on the TypeScript target compiler option to output a certain ECMA version. Instead we now use the browsers that are configured in the Browserslist configuration to determine which ECMA features and version are needed. This is done by passing the transpiled TypeScript to Babel preset-env.
**Note about useDefineForClassFields**: while setting this to `false` will output JavaScript which is not spec compliant, this is needed because TypeScript introduced class fields many years before it was ratified in TC39. The latest version of the spec have a different runtime behavior to TypeScript’s implementation but the same syntax. Therefore, we opt-out from using upcoming ECMA runtime behavior to better support the ECO system and libraries that depend on the non spec compliant output. One of biggest case is usages of the deprecated `@Effect` decorator by NGRX and potentially other existing code as well which otherwise would cause runtime failures. Dropping `useDefineForClassFields` will be considered in a future major releases. For more information see: https://github.com/microsoft/TypeScript/issues/45995.
BREAKING CHANGE: Internally the Angular CLI now always set the TypeScript `target` to `ES2022` and `useDefineForClassFields` to `false` unless the target is set to `ES2022` or later in the TypeScript configuration. To control ECMA version and features use the Browerslist configuration.
This commit adds an internal file to export needed symbols from `@angular/platform-server` when building a server bundle. This is needed. This is needed so that DI tokens can be referenced and set at runtime outside of the bundle.
Also, it adds a migration to remove these exports from the users files as otherwise an export collision would occur due to the same symbol being exported multiple times.
The usage of Stylus in the CLI is minimal and this package never reached version 1.
BREAKING CHANGE:
Deprecated support for Stylus has been removed. The Stylus package has never reached a stable version and its usage in the Angular CLI is minimal. It's recommended to migrate to another CSS preprocessor that the Angular CLI supports.
Remove deprecated support for ES5 output.
BREAKING CHANGE: Producing ES5 output is no longer possible. This was needed for Internet Explorer which is no longer supported. All browsers that Angular supports work with ES2015+
Support for the `fileReplacements` option from the Webpack-based builder has now been integrated into
the experimental esbuild-based browser application builder. The option will no longer be ignored during
builds. Only the officially supported form of the option (`replace`/`with` fields) is implemented.
The Browserslist configuration file is redundant as we set the defaults directly in @angular-devkit/build-angular. 8da926966e/packages/angular_devkit/build_angular/src/utils/supported-browsers.ts (L12-L19)
With this commit, we remove the `.browserlistrc` configuration file from the schematics application template and through a migration in existing projects when the Browserslist query result matches the default.
Users needing a finer grain support should still create a `.browserlistrc` in the root directory of the project.
Previously, when there was an error during a build that had service workers enabled, the dev-server crashed as the promise was rejected instead of emitting a compilation error.
With this change we update the logic so that any errors during the SW augmentation phase are changed to a compilation error and also update the logic so that when there are compilation errors we don't try to generate a SW.
esbuild 0.15.6 now supports transforming `for await..of` syntax and will now be used instead of babel
when the syntax is found within code that will be bundled. Zone.js requires that all async/await
related code be downleveled to properly hook promise callbacks. esbuild does not yet support
transforming async generators and so babel is still used when async generator syntax is detected
in an input file.
esbuild 0.15.6 also adjusted the `supported` option to imply that all dependent features of a
disabled feature are disabled as well. For the CLI, this allows only needing to specify that
`async-await` is disabled in the esbuild options.
The experimental esbuild-based browser application builder will now consider SVG files as
Angular component templates. Previously, only HTML files were considered templates and this
resulted in the esbuild-based builder to try to process the SVG file as a stylesheet.
This contains several minor adjustments to the setup steps for the experimental
esbuild-based browser application builder. It better groups the output directory
deletion and creation steps as well as moves entry point normalization into the
normalize options helper function. This should reduce the size of the main
execution function as well as aid in future profiling of the build phases.
The sourcemap URL in the output CSS files for global stylesheets is now correctly updated to
reflect the name of the global stylesheet output file and not the internal `stdin` virtual
file name.
Previously, the Sass compiler was imported on the start of every build regardless of its usage.
The Sass compiler will now only be loaded if a Sass stylesheet is requested.
When using the experimental esbuild-based browser application builder with Sass stylesheets, an
additional string creation for each output stylesheet will now be avoided when sourcemaps are disabled.
The global stylesheet processing using esbuild and the code bundling that also uses esbuild are now executed
asynchronously. Previously, the global stylesheet processing was required to wait until the code bundling was
complete before starting. Any warnings and/or errors for global stylesheets will also now be shown even if there
are errors during code bundling.
The global stylesheet bundling and processing code has been moved out of the main builder execution function
and into a separate function. This shortens the length of the main execution function for the builder and also
allows for further refactoring to allow the code and global stylesheet bundling to be executed at the same time.
PR #23691 introduced a regression that caused paranthesis in url not to be handled correctly.
This change correct this behaviour and adds a test case to valid this.
Closes#23773
CSS does not support the single line JS comment (`//`) but rather only the multi-line comment (`/* */`).
When generating the sourcemap URL comment with the modern Sass API, the multi-line comment syntax will
now be used. This removes the esbuild warnings per Sass file that would have otherwise been generated
when stylesheet sourcemaps are enabled for the build.
Stylesheet url tokens (`url(....)`) will now be processed when using the esbuild-based experimental browser
application builder. The paths will be resolved via the bundler's resolution system and then loaded
via the bundler's `file` loader. The functionality is implemented using an esbuild plugin to allow for all
file types to be supported without the need to manually specify each current and future file extension within
the build configuration.
The `externalDependencies` option also applies to the referenced resources. This allows for resource paths
specified with the option to remain unprocessed within the application output. This is useful if the relative
path for the resource does not exist on disk but will be available when the application is deployed.
With this change we replace Sass legacy with the modern API in the experimental esbuilder. The goal is that in the next major version this change is propagated to the Webpack builder.
Based on the benchmarks that we did Sass modern API is faster compared to the legacy version.
When using the experimental esbuild-based browser application builder, babel transformation
is now only performed on a file if the file requires the specific transformations enabled
for the build. This has the benefit of removing the need to parse and process files that
will not be affected by the enabled transformations.
From initial testing, this provides a 30% build time improvement for development builds of a
newly generated application and a 10% improvement for production builds.
esbuild now allows specifying whether individual JavaScript features should be supported in addition
to specifying the target JavaScript version for the output. This capability is now used to provide
the native async/await downleveling that is required by Zone.js when using the experimental esbuild-
based browser application builder. Since esbuild does not yet support downleveling async iteration
or async generators, Babel is still used when either of these syntax features are detected.
Previously, the RegExp didn't correctly handle cases where data URIs had escaped quotes like the below
```css
url("data:image/svg+xml;charset=utf-8,<svg width=/"16/" height=/"15/"></svg>")
```
Closes#23680
This dependency is only used to valid that node packages are resolved correctly.
With this change we mock the structure of font-awesome to avoid having to install it.
With this commit, we add a middleware that handles preflight requests as currently responses for this type of requests returning 404.
This is a temporary workaround until this issue is fixed upstream. See: https://github.com/webpack/webpack-dev-server/issues/4180Closes#23639
The esbuild-based experimental builder will now leverage the bundler to perform resolution of CSS imports.
This allows for more comprehensive resolution including packages which use the `sass` and/or `style` custom
conditions within a `package.json` exports field.
This PR includes a webpack plugin which adds a field to source maps that identifies which sources are vendored or runtime-injected (aka third-party) sources. These will be consumed by Chrome DevTools to automatically ignore-list sources.
When vendor source map processing is enabled, this is interpreted as the developer intending to debug third-party code; in this case, the feature is disabled.
Signed-off-by: Victor Porof <victorporof@chromium.org>
The `sourcemap.vendor` build option for the esbuild-based browser application builder will now
properly be considered when processing sourcemaps for third-party code (code originating from
a `node_modules` directory).
