With commits removes the several deprecated exceptions.
BREAKING CHANGE:
- `ContentHasMutatedException`, `InvalidUpdateRecordException`, `UnimplementedException` and `MergeConflictException` API from `@angular-devkit/core` have been removed in favor of the API from `@angular-devkit/schematics`.
- `UnsupportedPlatformException` - A custom error exception should be created instead.
The following unit tests have been ported over to test the experimental esbuild-based
browser application builder:
* `baseHref` option
* `crossOrigin` option
* TypeScript path mapping behavior
The deprecated 'defaultProject' workspace option has been removed
BREAKING CHANGE: The deprecated `defaultProject` workspace option has been removed. The project to use will be determined from the current working directory.
When using the internal JavaScript optimizer plugin for Webpack with an
empty script file provided via the `scripts` option, the build would fail.
This was because of a safety check that was checking whether the terser
result was falsy. Since an empty string is considered falsy, the build
considered the result to be an error. The safety check now will only trigger
if the terser result is not a string value to avoid this case.
G3 is now using RXJS version 7 which makes it possible for the CLI to also be updated to RXJS 7.
NB: this change does not remove all usages of the deprecated APIs.
Closes#24371
This PR removes the internally built `UpdateBuffer` and renames
`UpdateBuffer2` (based on magic-string) to `UpdateBuffer`. This
should have little to no impact for consumers.
BREAKING CHANGE:
The depracated `UpdateBuffer` has been removed and `UpdateBuffer2`
is renamed to `UpdateBuffer`. With this change the related and
deprecated symbols `ContentCannotBeRemovedException` and `Chunk`
have also been removed.
Use promise based methods to reduce RXJS usage and boiler-platting.
BREAKING CHANGE: Several changes to the `SchemaRegistry`.
- `compile` method now returns a `Promise`.
- Deprecated `flatten` has been removed without replacement.
The following unit tests have been ported over to test the experimental esbuild-based
browser application builder:
* `extractLicenses` option
* `main` option
* `optimization.styles.inlineCritical` option
* `styles` option
* `subresourceIntegrity` option
Several individual tests involving file output logging have been temporarily disabled
until build and file output logging has been implemented for the builder.
In some cases, using the `scripts` option caused a lot of `DescriptionFileUtils.loadDescriptionFile` calls which caused a bottleneck during build times.
The why to this is still unknown, but a workaround is to use the resolver from the Webpack compilation instead of the compiler.
Closes#24634
The `zone.js` package is currently built into a module structure form that resembles
UMD-like output. This causes the CommonJS checker within the experimental esbuild-based
browser application builder to issue a warning for `zone.js` usage. Until the packaging
of `zone.js` is updated to become fully ESM, the `zone.js` package is automatically allowed
when performing the CommonJS module check.
Within the build optimizer's static member optimization pass, a class that is directly
default exported must be split into two statements: the class declaration and the
default export. This is because the pass can wrap classes in a pure annotated IIFE which
results in a variable declaration replacement and variable declarations can not be directly
default exported. Previously, the pass did this splitting manually but this was causing
later babel plugins to fail. In addition to updating the AST in this case, scoping information
also needed to be updated. To support this, a babel helper package is now used that handles
the details of the statement split operation.
Update the `TypeScript compiler options "target" and "useDefineForClassFields" are set to "ES2022"` warning message to be more actionable.
Closes: #24697
With the additional of JIT mode and initial Less stylesheet support, the unit tests for the
`inlineStyleLanguage` build option can now be enabled for the experimental esbuild-based
browser application builder.
When using the experimental esbuild-based browser application builder, stylesheets written in the Less
stylesheet language can now be used throughout an application. The support allows Less stylesheets to
be used in all locations where CSS and/or Sass can be used. This includes global stylesheets and both
inline and external component styles. When using inline component styles, the `inlineLanguageStyle`
build option must be set to `less`.
Currently, import resolution within a Less stylesheet is limited to default Less behavior which does not
include full node package resolution. Full resolution behavior will be added in a future change.
The build optimizer's static class field pass will now additionally wrap
classes that contain side effect free class properties. This allows optimizers and
bundlers further along in the build pipeline to downlevel that class properties while
still retaining the ability to tree-shake the class if unused. The class properties
may need to be downleveled for a variety of reasons such as lack of browser support,
browser bugs with certain code structures, or to ensure spec-compliant runtime behavior.
The following unit tests have been ported over to test the experimental esbuild-based
browser application builder:
* `assets` option
* `outputHashing` option
* browser support behavior (`browserslist`)
Several small modifications were necessary to accommodate output file differences such
as no runtime chunk. Additionally, two tests are temporarily disabled for the `outputHashing`
tests pending implementation in the builder. These tests are the same stylesheet resource handling
file name test and no hashing of non-injected styles test.
The Builder test harness previously used the deprecated `TestProjectHost` to perform a
variety of file operations during builder unit tests. However, the `TestProjectHost` is
deprecated and uses several layers of rxjs to perform the file operations. The test harness
now uses the Node.js `fs` builtin to directly perform the file operations. This removes several
layers of indirection between the harness and the actual underlying file operations. The removal
of the rxjs operation chaining also reduces stack traces and makes debugging test issues less
complicated.
Previously, we failed the compilation when the specified patterns did not match any spec file. This breaks the case were users configure Karma to not fail on empty test suit.
Closes#24644
This commit updates changes the way polyfills and runtime are loaded from modules to scripts. This is required as otherwise Jasmine will be loaded prior to Zone.js which causes clock patching not to work.
Closes#24651
When using the experimental esbuild-based browser application builder, the `aot` build option
can now be set to `false` to enable JIT compilation mode. The JIT mode compilation operates
in a similar fashion to the Webpack-based builder in JIT mode. All external Component stylesheet
and template references are converted to static import statements and then the content is bundled
as text. All inline styles are also processed in this way as well to support inline style languages
such as Sass. This approach also has the advantage of minimizing the processing necessary during rebuilds.
In JIT watch mode, TypeScript code does not need to be reprocessed if only an external stylesheet
or template is changed.
* test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
* fixup! test: run legacy-cli e2e tests via bazel
The workspace writer previously transformed number like strings to numbers which causes failures when a project is named using a number like name.
Closes#24541
When using Sass with the experimental esbuild-based browser application builder, bare imports
without a path segment that were available via included paths but also happen to be a node module
could cause an exception. An example of such an import would be `@import "globals";`. The deep
import node module logic would previously attempt to join an undefined path segment to the resolved
path for the `globals` package which would raise a argument type exception. This case has now been
fixed by only joining if there is actually a path segment present such as `@import "globals/x"`.
With this fix in place, the node module case can then continue and if no stylesheet is found, the
include paths will then be searched.
Due to the update of the experimental esbuild-based browser application builder to use esbuild 0.17,
the watch mode has been changed to use the new incremental API. The previous API has been removed
from esbuild. The new API involves creating a build context object that can then be used to perform
rebuilds of the configured application bundler as needed. All watch mode usage has been updated to
use this new approach. An effort was made to minimize the amount of changes made to support this API
update and limit the changeset. However, further refactoring will be possible as additional capabilities
are added in the future.
esbuild API reference: https://esbuild.github.io/api/#rebuild
When using the experimental esbuild-based browser application builder and an exception is thrown
during the initial build, the process may hang indefinitely due to the Sass worker pool not
shutting down fully. This does not happen for rebuilds after the initial. To remedy this
situation, The initial build is now wrapped in a try block to ensure that a full shutdown
of the Sass worker pool occurs.
When using the experimental esbuild-based browser application builder, input files
for the build will now be checked to determine if they are non-ESM modules. This
behavior is comparable to the existing behavior within the default Webpack-based browser.
Warnings will now be issued for any non-ESM modules (for example, CommonJS or UMD) when
script optimizations are enabled (typically production builds). ESM files can be tree-
shaken and otherwise optimized in ways that CommonJS files cannot which allows for
more optimized and smaller output bundle files.
If any allowed dependencies are provided via the `allowedCommonJsDependencies`
option, both the direct import and any deep imports of the dependency will be ignored
during the checks and no diagnostic will be generated for the dependency.
The i18n inlining worker code was previously imported in several locations to allow
reuse of the options object used to configure the worker. To prevent the worker
code from being used outside of an actual worker, the options object definition is
now located in a separate file and imported in both the worker and any other files
that need to use the inlining options.
