For the `rules_js` migration we are introducing a new ruleset for
Angular rules. These rules are not used here by the CLI as we don't use
`ng_module`, but we are building the rules in a way where we expose a
worker binary that can also work with vanilla TS.
The worker significantly speeds up compilations, bringing them to
equivalent speeds of `ts_library`, and **importantly** fixes/avoids
issues when actions are executing outside sandbox. E.g. on Windows where
the tsc compilation currently can see many other files that aren't
action inputs; and accidentally picks them up.
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.
In our dev-infra sync we decided that we want to have less
ambiguous naming for node modules from the workspace root vs. node
modules that are local to the package.
Consider the confusion between: `//:node_modules` and `:node_modules`.
This commit fixes this by naming the workspace `node_modules` as
`:root_modules`. This does not have an effect on runtime of NodeJS
output because `rules_js` continues to lay out the root modules as
`/node_modules` folder; as it should.
- it seems to be disabled by default for actual production .ts files;
but the rule is in "error" mode for spec files.
- The rule doesn't seem to properly support mono-repos when configured properly.
i.e. it only considers the top-level package.json — hence doesn't deal with cross-workspace deps.
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.
This commit updates the architect devkit package code to use
`ts_project`. We specificially don't migrate the jasmine node test yet
as we want to experiment further with the incremental migration.
This is necessary as the current rule is not clever enough to detect
when a given file is already "generated" and inside `bin`.
This is important because `package.json` files are always copied to bin
for `npm_package`, but the `package.json` may already be copied from
e.g. `ts_project#data`. This shouldn't cause a Bazel action conflict.
This commit introduces a new interop Starlark macro/rule for using
`ts_project` throughout the repository without having to migrate
any dependant or dependencies; allowing for incremental migration
to `ts_project`.
This also requires us to move patches from `patch:` protocol to
`patch-package` temporarily. This is because we need to temporarily use
pnpm and yarn berry in hybrid, and both don't have any overlap in how
patching works; and pnpm would fail if it sees the `patch` protocol.
This is necessary for an incremental migration to `rules_js` which
requires Bazel v6. Bazel v6 removed the managed directories feature,
which means we no longer can rely on symlinked node modules as the Bazel
repository; but rather need to duplicate dependencies. This is
okay/acceptable to enable the incremental migration.
A timeout was added during route extraction to resolve an issue where 'adev' would hang in production builds.
The root cause is currently unclear, but this change ensures the build completes successfully.
The experimental chunk optimizer is now only imported if it is enabled
via its environment variable (`NG_BUILD_OPTIMIZE_CHUNKS=1`). This prevents
the loading of the rollup package as well as any transitive dependencies
when these packages will not be used by the build.
When using component HMR and SSR with the development server, the component
update modules will now be available to the Vite server rendering. This
prevents console errors due to missing component update paths. Additionally,
it allows the server rendering to use the latest component templates if those
have been changed before a new rebuild has occurred.
To ensure that component HMR identifiers match correctly during an update,
the path element of the identifier generated by the build system will now
convert all windows path separators into POSIX separators. This provides
matching behavior to the AOT compiler's identifier generation process.
- <script> is the last tag before </head> close
- .appendChild is called before </head> (because document.body is undefined then)
- <script> tags with a src attribute and no specified type attribute should not write <script type="undefined" ...>
When users access the root route `/` without providing a locale, the application now redirects them to their preferred locale based on the `Accept-Language` header.
This enhancement leverages the user's browser preferences to determine the most appropriate locale, providing a seamless and personalized experience without requiring manual locale selection.
Enhance performance when using SSR by adding `modulepreload` links to lazy-loaded routes. This ensures that the required modules are preloaded in the background, improving the user experience and reducing the time to interactive.
Closes#26484
This commit introduces `ngServerMode` to ensure proper handling of external `@angular/` packages when they are used as externals during server-side rendering (SSR).
Closes: #29092
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
