Migrates the `@angular-devkit/build-angular` tests to `rules_js`. This
was a rather larger undertaking as the tests were very reliant on e.g.
the directory structure or specific node module layout; so some changes
were needed.
- the Sass files include a much larger file header now. That is because
the npm Sass files have much larger paths, given being inside a
symlinked pnpm store directory. E.g.
```
/*!**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************!*\
!*** css ../../../../../node_modules/.aspect_rules_js/css-loader@7.1.2_webpack_5.97.1/node_modules/css-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[1]!../../../../../node_modules/.aspect_rules_js/postcss-loader@8.1.1_1462687623/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[4].rules[0].oneOf[0].use[2]!./src/test-style-a.css?ngGlobalStyle ***!
\**********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************/
.test-a {color: red}
```
- Similarly to above, hashed chunk files can change given different
paths of e.g. Webpack, or external sources.
- Tests for verifying the lazy module chunks may enable
`preserveSymlinks` just to make the chunk names shorter and easier to
verify, avoiding truncatd super long paths to the e.g. pnpm stores
again.
- the ngsw-worker.js file cannot be copied using `copyFile` as that
results in permissions being copied as well. In Bazel, now that
the npm files are properly captured, are readonly, so subsequent
builds (e.g. the watch tests) will fail to copy/override the file
again! Reading and writing the file consistently seems appropriate.
- Tests relying on puppeteer and webdriver-manager worked in the past,
by accident, because postinstall scripts (from e.g. puppeteer) were
able to modify content of other packages (e.g. the puppeteer-core
cache of browsers then). This does not work with `rules_js` anymore,
so we need to keep the cache local to the puppeteer postinstall
script. This requires a little trickery right now to ensure resolution
of the browsers at runtime works..
- server tests did miss the `node` types to be explicitly listed (as
they would be in a fresh project), and this caused failures. Likely
because we no longer patch resolution.
- avoid npm-module style imports from tests within the same package.
This is not allowed with `rules_js` and also is inconsistent.
To support usage of the newly released Tailwind CSS 4.0.0, the peer dependency
range has been update to include `^4.0.0`. This prevents potential installation
warnings/error when using various package managers.
Use of Tailwind CSS 4+ requires either the `application` (new project default) or
`browser-esbuild` builder. Both of which support custom postcss configuration
via a `.postcssrc.json` file.
For instructions on the setup of Tailwind CSS with Angular, please see the
Tailwind CSS documentation here: https://tailwindcss.com/docs/installation/framework-guides/angular
Disables TypeScript's `removeComments` option to ensure important annotations like `/* @__PURE__ */`
and `/* vite-ignore */` are preserved. TypeScript's comment removal can be too aggressive,
potentially stripping out critical information needed by bundlers for dead code elimination.
Non-essential comments will be handled by the bundler, so removing them in TypeScript isn't necessary
and could lead to an increase in the final bundle size.
Closes#29470
Vite version 6.0.9+, which is now used by the Angular CLI, contains a potentially
breaking change for some development setups. Examples of such setups include those
that use reverse proxies or custom host names during development. The change within
a patch release was made by Vite to address a security vulnerability. For
projects that directly access the development server via `localhost`, no changes should
be needed. However, some development setups may now need to adjust the newly
introduced `allowedHosts` development server option. This option can include an array
of host names that are allowed to communicate with the development server. The option
sets the corresponding Vite option within the Angular CLI.
For more information on the option and its specific behavior, please see the Vite
documentation located here:
https://vite.dev/config/server-options.html#server-allowedhosts
The following is an example of the configuration option allowing `example.com`:
```
"serve": {
"builder": "@angular/build:dev-server",
"options": {
"allowedHosts": ["example.com"]
},
```
Additional details on the vulnerability can be found here:
https://github.com/vitejs/vite/security/advisories/GHSA-vg6x-rcgg-rjx6
By converting schemas from TypeScript `interfaces` to `types`, we can minimize the reliance on `json.JsonObject`. This approach avoids the error "Type 'Schema' does not satisfy the constraint 'JsonObject'" caused by the missing index signature for type 'string' in 'Schema'.
This is necessary as `rules_js` requires this "common name" when dealing
with Yarn workspaces, linking first party dependencies automatically.
In the future, we may be able to send a PR to `rules_js` to support a
custom name somehow.
* Removes `interop_deps` from the `ts_project` interop macro.
* Keeps `_rjs` suffix for now as we still need the interop targets for
e.g. `jasmine_node_test` and the `rules_nodejs` linker.
In follow-ups we can remove the suffix, and interop layer.
We should only force the type for files that we know are JavaScript.
Otherwise we risk breaking the magic type detection done by Karma.
The previous code broke for `jasmine.css`.
Fixes https://github.com/angular/angular-cli/issues/29190
This reverts commit 3af88fef8b3255971cc20034d31b01012b7cacb3.
No longer needed because the interop lays out the node modules directory
like without the interop & `ts_project` migration; so the chunk name
changed back to what it was before. Good news.
This commit updates `build_angular` to the `rules_js` ts_project rule.
Notably a few real type issues surfaced but previously didn't surface
due to some unknown resolution issues that resulted in `never` types;
where every possible value was assignable; so this change improves type
safety and a TODO was left for the "brittle code fragment".
Currently the interop resulting target of a `ts_project` ends up not
necessarily working at runtime. This may be the case because a consuming
Node program may end up with mixes of `node_modules` dependencies from
`rules_nodejs` (old) and `rules_js` (new). This sounds fine at first
glance, but in practice can break very subtly because:
* Rules NodeJS leverages the linker, creating `node_module` directories
outside of Bazel, at runtime. These don't depend on symlink resolving.
* Rules JS puts real node module folders via Bazel actions. These rely
on `pnpm` non-hoisting layout, and symlink resolving.
As we can see there is a hard conflict with symlinks. They need to be
enabled with the new toolchain, but the other one doesn't enable symlink
resolution, and enabling is not possible as we'd otherwise risk escaping
the sandbox and cause even more subtle errors.
A good compromise solution is to automatically drop the `rules_js` node
module files/folder in the interop-`rules_nodejs` target and instead
brining in the equivalent `@npm//` dependencies from `rules_nodejs`.
This kind of keeps the logic similar to when not using `rules_js` or the
interop, and enables the simplest & safest mental model; and it works
compared to other solutions I tried with symlinking. Notably, we can't
keep both node module variants as the linker doesn't override existing
node module files from e.g. rules_js then (and would break then).
I suspect there were some versioning changes with the e.g. `hoist =
false` setting in npmrc; so eslint now starts failing about an import
from `webpack-server.ts` resulting in unnecessary type cast lint errors.
The existing mapping didn't work due to the underscore conversion, so
this makes sense, and fixing the path mappings works.
I suspect there were some versioning changes with the e.g. `hoist =
false` setting in npmrc; so eslint now starts failing about this
unnessary type cast. Seems reasonable so this is committed without
deep investigation.
It seems that the chunk deterministic name has changed after
recent node module /lock file changes. It's unclear what specifically is
involved in Webpack's chunk name generation, but the output and all
other tests still look good; which makes this is a rather safe update to
the new chunk name. Consulting with CLI team members explained that this
can happen quite often.
Previously, the `baseHref` option under each locale allowed for generating a unique base href for specific locales. However, users were still required to handle file organization manually, and `baseHref` appeared to be primarily designed for this purpose.
This commit introduces a new `subPath` option, which simplifies the i18n process, particularly in static site generation (SSG) and server-side rendering (SSR). When the `subPath` option is used, the `baseHref` is ignored. Instead, the `subPath` serves as both the base href and the name of the directory containing the localized version of the app.
Below is an example configuration showcasing the use of `subPath`:
```json
"i18n": {
"sourceLocale": {
"code": "en-US",
"subPath": ""
},
"locales": {
"fr-BE": {
"subPath": "fr",
"translation": "src/i18n/messages.fr-BE.xlf"
},
"de-BE": {
"subPath": "de",
"translation": "src/i18n/messages.de-BE.xlf"
}
}
}
```
The following tree structure demonstrates how the `subPath` organizes localized build output:
```
dist/
├── app/
│ └── browser/ # Default locale, accessible at `/`
│ ├── fr/ # Locale for `fr-BE`, accessible at `/fr`
│ └── de/ # Locale for `de-BE`, accessible at `/de`
```
DEPRECATED: The `baseHref` option under `i18n.locales` and `i18n.sourceLocale` in `angular.json` is deprecated in favor of `subPath`.
The `subPath` defines the URL segment for the locale, serving as both the HTML base HREF and the directory name for output. By default, if not specified, `subPath` will use the locale code.
Closes#16997 and closes#28967
