Prior to this change using an absolute path as a `output-path` resulted in the path to be combined with the workspace root instead of resolved which caused the output to be emitted in the incorrect directory or error in Windows.
Closes#26935
The `load` event for each stylesheet may not always be triggered by Google Chrome's handling. Refer to: https://crbug.com/1521256
This results in the media attribute persistently being set to print, leading to distorted styles in the UI. To address this issue, we substitute the onload logic by replacing `link.addEventListener('load', ...` with `document.documentElement.addEventListener('load', ...` and filtering for link tags.
Closes#26932
Vite v5 updated the client code's error dialog text. This requires that the
text replacement code also be updated to remove unactionable information from
the error dialog.
Previously, the `application` builder would consider all imports originating from a package
to be considered external when caching was enabled. This allows Vite's prebundling to function
and optimize the build/rebuild experience for the development server. However, when using the
newly introduced `loader` option, this also inadvertently caused files that should be affected
by the option that originate from a package to also be considered external. This behavior would
then prevent the loader customization from being performed. To rectify this situation, all files
that would be affected by a loader customization will not be marked as external for the purposes
of prebundling unless explicitly configured by the `externalDependencies` option.
This commit fixes a regression which causes a pre-transform error when using vite with ssr. The `request.url` is now passed to the index transformer instead of `request.originalUrl`. This is because the `request.url` will have a value of the `index.html`.
Closes#26897
Previously, we `joined` the workspace root with the `outputFile.path`, in windows this caused a problem as during the 2nd rebuild it caused the workspace root to be prepended again which causes a `ENOENT` error. To avoid this problem, now we `clone` the output file.
Closes#26900
To reduce the amount of code within the main Vite development server file, the Vite plugin
that handles the in-memory output file integration for the Angular build system is now within
a separate file.
To support generate diagnostics in varying ways, the internal compilation classes
now support a `modes` argument when diagnosing files during a build using the `application` builder.
This is not exposed as an option at this time but can be experimented with a build using the
`NG_BUILD_TYPE_CHECK` environment variable. This environment variable is not considered part of the
public API and may be removed or altered in the future. Its current purpose is to allow profiling
of the type checking diagnostics functionality of the build system.
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 logging of diagnostic (error/warning) messages from the build execution within the
`application` builder has been moved up one level. This allows the actual execution to
focus more on generating a result and leaves the enclosing builder system to handle
notification of the results.
To reduce the amount of code within the main `application` builder execution function,
the bundler context setup has been moved into a separate file. This also reduces the
amount of imports within the main execution function's module.
To improve the readability and discoverability of any warnings or errors present
during build, the diagnostic messages will be shown after the build stats are
displayed. For large projects the amount of generated files previously could cause
warnings to scroll off the screen and potentially be missed.
Turns out this isn't needed for `application` builder to correctly resolve inputs. Not using `process.cwd` should make this builder a little less brittle for monorepo use cases or when running `ng test` inside a subdirectory.
This is a new `@angular-devkit/build-angular:web-test-runner` builder which invokes Web Test Runner to execute unit tests in a real browser.
The implementation calls `application` builder under the hood with some option overrides build the application to a temporary directory and then runs Web Test Runner on the output. This set up is still minimal, but sufficient to run and pass tests in the generated `ng new` application.
The `schema.json` file is directly copied from the `karma` builder, since this is intended to serve as a migration target for users coming from Karma. Most of the options don't actually work yet, which is logged when they are used.
The most interesting part of this change is configuring Jasmine to execute in Web Test Runner. This is done through the `testRunnerHtml` option which allows us to control the HTML page tests are executed on. We use `test_page.html` which very carefully controls the loading process. I opted to make a single `<script type="module">` which dynamic imports all the relevant pieces so the ordering can be directly controlled more easily. This is better than trying to manage multiple `<script>` tags and pass data between them. Ideally everything would be bundled into a single entry point, however this is not feasible due to the way that ordering requirements do not align with typical `import` structure. Jasmine must come before polyfills which must come before the runner which invokes user code. In an ideal world, this ordering relationship would be represented in `import` statements, but this is not practically feasible because Angular CLI doesn't own all the files (`./polyfills.js` is user-defined) and Jasmine's loading must be split into two places so Zone.js can properly patch it.
`jasmine_runner.js` serves the purpose of executing Jasmine tests and reporting their results to Web Test Runner. I tried to write `jasmine_runner.js` in TypeScript and compile it with a `ts_library`. Unfortunately I don't think this is feasible because it needs to import `@web/test-runner-core` at runtime. This dependency has some code generated at runtime in Web Test Runner, meaning we cannot bundle this dependency and must mark it as external and dynamic `import()` the package at runtime. This works fine in native ESM, but compiling with TypeScript outputs CommonJS code by default (and I don't believe our `@build_bazel_rules_nodejs` setup can easily change that), so any `import('@web/test-runner-core')` becomes `require('@web/test-runner-core')` which fails because that package is ESM-only. The `loadEsmModule` trick does work here either because Web Test Runner is applying Node module resolution at serve time, meaning it looks for `import('@web/test-runner-core')` and rewrites it to something like `import('/node_modules/@web/test-runner-core')`. In short, there is no easy syntax which circumvents the TypeScript compiler while also being statically analyzable to Web Test Runner.
Previously an entry point `foo` would be incorrectly treated as a relative path, which meant it was not possible to use an NPM package as an entry point. This now requires `./foo` for relative paths while `foo` is treated as a module specifier referring to an NPM package called `foo`.
Due to the file structure of Bazel Windows builds, type annotations are
required in certain locations to successfully build the project. Function
return type annotations are generally recommended anyway within the code.
