Yarn 1.x sometimes does not clean up unneeded nested node modules, and this breaks some strict assumption in the Bazel NodeJS yarn install. This commit bumps the version in the cache key to make sure there is no stale cache that is used in CI jobs (that is causing issues with that CI job).
PR Close#44843
Bundlers like Rollup may use an element access expression for an export
declaration, which causes ngcc to ignore those export declarations possibly
resulting in incomplete processing of packages.
Element access syntax may be used when the declared name is not considered
as valid JS identifier, but bundlers may be conservative in determining whether
an identifier can be used (to emit a property access) and opt for a string
literal in an element access instead.
The element access syntax introduces a problem for ngcc, where it wouldn't
consider such export as class declaration, causing them to be skipped. The
ngtsc compiler is implemented with the assumption that all class declarations
use a `ts.Identifier` as name, whereas the element access is using a string
literal for the declared name. This makes it troublesome for ngcc to support
this syntax form in UMD bundles.
To work around the problem, this function transforms these access expressions
into regular property accesses. The source text is parsed to an AST to allow
finding the element accesses in a robust way, after which the affected text
ranges are replaced with property accesses in the original source text.
Closes#44037
PR Close#44824
Previously, when processing UMD, ngcc assumed that the `exports`
argument of the CommonJS factory call (if present) would be the first
argument of the call. This is generally true for the supported UMD
formats, but can change if ngcc prepends more imports (and thus factory
arguments) while processing the module. This could lead to errors when
trying to collect dependencies of an already processed module.
(This was accidentally broken in #44245 (commit 2bc3522e16).)
This commit fixes it by not making any assumptions about the position of
an `exports` argument in the CommonJS factory call.
Fixes#44380
PR Close#44382
Previously, the mock packages created for `UmdDependencyHost`'s tests,
specified the entry-point as `esm2015`. This does not matter in tests,
since the packages are explicitly passed to the `UmdDependencyHost`
(while in reality the appropriate host would be determined based on the
name of the entry-point property - in this case, detecting the
entry-point as ES2015 and not UMD).
However, in order to avoid confusion, this commit updates the test
packages to use `main` (the default property used for the UMD format in
`package.json` files).
PR Close#44245
Previously, the ngcc `UmdReflectionHost` would throw a misleading error
when trying to collect dependencies of an invalidly formatted UMD
module. This happened because an error would be thrown while trying to
construct the error message for the actual error, by calling `getText()`
on certain TypeScript AST nodes. See
https://github.com/angular/angular/issues/44019#issuecomment-959954121
for a more in-depth explanation.
This commit ensures `getText()` can be safely called on TypeScript AST
nodes when collecting dependencies of UMD modules.
PR Close#44245
This commit utilizes the infrastructure added in the previous commit to
run more tests against more of the supported UMD formats. This shall
give us more confidence that all aspects of UMD processing work
correctly with the various formats.
PR Close#44245
Previously, several ngcc test suites used their own helper to generate
test UMD modules.
This commit switches to using the same helper for generating UMD modules
across test suites. This improves DRYness (ensuring changes/fixes to the
UMD format need only be applied once) and makes it easier to test
different UMD formats in all test suites.
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup.
This commit adds support for a different format, that uses `if/else`
statements, which is what is [emitted by Webpack][1].
[1]: https://webpack.js.org/configuration/output/#type-umdFixes#44019
PR Close#44245
Previously, ngcc could only handle UMD modules whose wrapper function
was implemented as a `ts.ConditionalExpression` (i.e. using a ternary
operator). This is the format emitted by popular bundlers, such as
Rollup. However, this failed to account for a different format, using
`if/else` statements, such as the one [emitted by Webpack][1].
This commit prepares ngcc for supporting different UMD wrapper function
formats by decoupling the operation of parsing the wrapper function body
to capture the various factory function calls and that of operating on
the factory function calls (for example, to read or update their
arguments). In a subsequent commit, this will be used to add support for
the Webpack format.
[1]: https://webpack.js.org/configuration/output/#type-umd
PR Close#44245
When a partially compiled component or directive is "linked" in JIT mode, the body
of its declaration is evaluated by the JavaScript runtime. If a class is referenced
in a query (e.g. `ViewQuery` or `ContentQuery`) but its definition is later in the
file, then the reference must be wrapped in a `forwardRef()` call.
Previously, query predicates were not wrapped correctly in partial declarations
causing the code to crash at runtime. In AOT mode, this code is never evaluated
but instead transformed as part of the build, so this bug did not become apparent
until Angular Material started running JIT mode tests on its distributable output.
This change fixes this problem by noting when queries are wrapped in `forwardRef()`
calls and ensuring that this gets passed through to partial compilation declarations
and then suitably stripped during linking.
See angular/components#23882 and angular/components#23907
PR Close#44124
Prior refactorings caused unexpected g3 sync issues due to a patch that
changes the error documentation URL. This commit moves the base url into
a separate file to make this more apparent.
PR Close#43965
The `ErrorCode` enum in the `error_code.ts` file is governed by public
api guards but the other top-level exports from that file are exempt
from public api documentation and are therefore marked as `@internal`.
However, TypeScript is configured with the `stripInternal` compiler
option such that declarations with `@internal` markers are not emitted
into the `.d.ts` files, but this means that the reexports in the barrel
file end up referring to missing declarations.
The `stripInternal` option is considered internal and its documentation
states to use at your own risk (as per https://github.com/microsoft/TypeScript/issues/45307).
Having the option enabled is desirable for us as it works well for
hiding class fields that are marked `@internal`, which is an effective
way to hide members from the .d.ts file. As a workaround for the issue
with top-level symbols, the declarations with `@internal` markers are
moved to dedicated files for which no public api guard is setup,
therefore allowing their `@internal` markers to be dropped.
Fixes#43097
PR Close#43965
This fixes an issue on Safari which caused the text to be pushed down when blurring out of the search input field. The root cause of the problem appears to be that previously the computed line height was that of 32px, which caused a shift in content.
Closes#43935
PR Close#43983
Previously, there were two ways to disable view transition animations in
`DocViewerComponent`: Using a `.no-animations` CSS class on the
`<aio-doc-viewer>` element and setting the static
`DocViewerComponent.animationsEnabled` property to `false`. The latter
was only used to disable animations for testing purposes.
With the recent introduction of `AppComponent.reducedMotion`, there is
now an easy way to disable animations in tests using the
`.no-animations` class (which is applied by `AppComponent` based on the
value of `AppComponent.reducedMotion`). Therefore, it is no longer
necessary to have `DocViewerComponent.animationEnabled`.
This commit removes the now obsolete `animationsEnalbed` property.
PR Close#43977
Previously, the master branch was only deployed to the
`next-angular-io-site` Firebase site, which is connected to the
`next.angular.io` domain. However, if the master major version was
higher than the stable major version (or the RC major version in case
there was an active RC), we also had to manually configure (via the
Firebase console and/or DNS records) the `v<X>.angular.io` domain to
redirect to `next.angular.io`. Then, once `<X>` became the new stable or
RC version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io` or `rc.angular.io`).
This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply when the master major version is
higher than the current stable and RC (if applicable)):
- A `v<X>-angular-io-site` Firebase site will be created as soon as the
version in the `master` branch's `package.json` is updated to a new
major.
- The `v<X>.angular.io` domain will be connected to that new Firebase
site.
- When deploying from the master branch, we will deploy to both
`next-angular-io-site` and `v<X>-angular-io-site`. In addition, the
deployment to `v<X>-angular-io-site` will update the Firebase config
file to redirect to `next.angular.io`.
- When the master version becomes the new stable/RC, we will start
deploying to `v<X>-angular-io-site` from the stable/RC branch, which
will update the Firebase config to stop redirecting to
`next.angular.io` and redirect to `(rc.)angular.io` instead (without
requiring changes in the Firebase console or DNS).
PR Close#43963
Previously, (when there was an active RC) the RC branch was only
deployed to the `rc-angular-io-site` Firebase site, which is connected
to the `rc.angular.io` domain. However, if the RC major version was
higher than the stable major version, we also had to manually configure
(via the Firebase console and/or DNS records) the `v<X>.angular.io`
domain to redirect to `rc.angular.io`. Then, once `<X>` became the new
stable version, we had to manually remove the redirect (to let
`v<X>.angular.io` be redirected to `angular.io`).
This commit is part of a new process that reduces the manual steps as
follows (the steps below only apply to RC versions that have a higher
major version than the current stable):
- A `v<X>-angular-io-site` Firebase site will be created for the new RC
version.
- The `v<X>.angular.io` domain will be connected to that new Firebase
site.
- When deploying from the RC branch, we will deploy to both
`rc-angular-io-site` and `v<X>-angular-io-site`. In addition, the
deployment to `v<X>-angular-io-site` will update the Firebase config
file to redirect to `rc.angular.io`.
- When the RC version becomes the new stable, we will start deploying to
`v<X>-angular-io-site` from the stable branch, which will update the
Firebase config to stop redirecting to `rc.angular.io` and redirect to
`angular.io` instead (without requiring changes in the Firebase
console or DNS).
PR Close#43963
Previously, the stable branch was always deployed to the
`v<X>-angular-io-site` Firebase site, which was connected to the
`angular.io` domain. Whenever a new major version was released (and
became the new stable version), the `angular.io` domain had to be
disconnected from the previous Firebase site and be connected to the new
`v<Y>-angular-io-site` Firebase site. This was a manual process that
involved making changes in the Firebase console and the DNS records.
This commit is part of a new process that reduces the manual steps as
follows:
- A new `stable-angular-io-site` Firebase site is created.
- The `angular.io` domain will be connected to that new Firebase site.
- When deploying from the stable branch, we will deploy to both
`stable-angular-io-site` and `v<X>-angular-io-site`. In addition, the
deployment to `v<X>-angular-io-site` will update the Firebase config
file to redirect to `angular.io`.
- When a new major version is released, we will start deploying from the
new stable branch to `stable-angular-io-site`, but there will be no
need to connect/disconnect the `angular.io` domain. Also,
`v<X>.angular.io` will stop redirecting to `angular.io` by means of
updating the Firebase config file (without requiring changes in the
Firebase console or DNS).
PR Close#43963
Add `deploy-to-firebase` post-deploy actions to allow testing various
redirect configs.
In a future commit, this will allow testing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).
PR Close#43963
Refactor the `deploy-to-firebase` post-deploy actions by extracting
logic to separate helper functions. This makes it easier to create more
functions for testing various redirect configs (in a future commit).
PR Close#43963
Previously, there was a `deploy-to-firebase` pre-deploy action for
configuring Firebase to redirect non-file requests to `angular.io`. This
is used for ensuring that `rc.angular.io` is correctly redirected to
`angular.io`, even when people have previously visited (and have a
ServiceWorker activated on) `rc.angular.io`.
This commit adds pre-deploy actions for configuring Firebase to redirect
a deployment to any of `angular.io`, `rc.angular.io` or
`next.angular.io` and also configure whether all requests or only
non-file requests will be redirected.
In a future commit, this will allow managing redirects for the `stable`,
`rc` and `next` deployments via the Firebase config file (without
requiring changes in the Firebase console or DNS).
PR Close#43963
Create functions to undo the changes made by any pre-deploy action.
In a future commit, this will allow deploying a build to multiple
projects/sites with different small tweaks for each.
PR Close#43963
Previously, the pre-computation of branch version info for the
`deploy-to-firebase` tests would always take place even when the tests
that used that info were skipped. This pre-computation involves network
access and may add a noticeable delay.
This commit refactors the tests to not do the pre-computation if the
corresponding tests are skipped. This allows for a faster iteration
when focusing on a different set of tests.
PR Close#43963
Move some functions that are used as post-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/post-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.
NOTE:
While not strictly necessary atm, `post-deploy-actions.mjs` uses the
same default export pattern for consistency with `utils.mjs`.
PR Close#43963
Move some functions that are used as pre-deploy actions from
`deploy-to-firebase/index.mjs` to a separate file
(`deploy-to-firebase/pre-deploy-actions.mjs`) to keep `index.mjs` small
and easier to maintain.
Also, rename the `removeServiceWorker()` function to
`disableServiceWorker()`, which is a little more accurate.
NOTE:
While not strictly necessary atm, `pre-deploy-actions.mjs` uses the same
default export pattern for consistency with `utils.mjs`.
PR Close#43963
Move some util functions from `deploy-to-firebase/index.mjs` to a
separate file (`deploy-to-firebase/utils.mjs`) to keep `index.mjs` small
and easier to maintain.
NOTE:
To make it easier to mock functions in tests, `utils.mjs` uses a default
export (instead of multiple named exports) and references local
functions through the default exported object.
PR Close#43963
The `deploy-to-firebase` script might have to deploy a single AIO build
to multiple projects/sites (potentially with small tweaks between each).
This commit adds a step to validate the computed deployments to ensure
they are compatible with each other (for example, that there is exactly
one primary deployment that builds the app and sets the theme/mode and
that all secondary deployments are compatible with the primary one).
PR Close#43963
This commit adds two new properties, `name` and `type`, to deployment
info data. This will make it easier to differentiate between deployment
targets (e.g. primary vs secondary) and will provide more informative
log messages.
In a subsequent commit, this new data can be used to validate the
computed deployments list.
PR Close#43963
This commit fixes a typo in an error message thrown in the
`deploy-to-firebase` script (`but it was but it was` --> `but it was`).
It also makes the error clearer when the request was not redirected.
Old error:
> Expected '<original-url>' to be redirected to '<expected-url>', but it
> was but it was redirected to 'undefined'.
New error:
> Expected '<original-url>' to be redirected to '<expected-url>', but it
> was not redirected.
PR Close#43963
This commit enables linting for the scripts in
`aio/scripts/deploy-to-firebase/`. It also makes the necessary changes
to the files to make linting pass.
PR Close#43963
This commit moves the `aio/scripts/deploy-to-firebase.js` script into a
new directory, `aio/scripts/deploy-to-firebase/`. This will make it
easier to break it up into multiple smaller files to better organize the
code (without polluting the `aio/scripts/` directory).
PR Close#43963
The `InjectFlags` argument was defined for both `getOrCreateInjectable()` and `Injector`, but was ignored in `NodeInjector`.
This PR adds support for getting parent token via `NodeInjector.get()`.
close#31776
PR Close#41592
Fix incorrect escape of special characters when rendering member heritage docs. Example: DefaultIterableDiffer docs incorrectly renders what this class implements - it does not fully display generic types of implemented interfaces.
PR Close#43956
Prior refactorings caused unexpected g3 sync issues due to a patch that
changes the error documentation URL. This commit moves the base url into
a separate file to make this more apparent.
PR Close#43527
The `ErrorCode` enum in the `error_code.ts` file is governed by public
api guards but the other top-level exports from that file are exempt
from public api documentation and are therefore marked as `@internal`.
However, TypeScript is configured with the `stripInternal` compiler
option such that declarations with `@internal` markers are not emitted
into the `.d.ts` files, but this means that the reexports in the barrel
file end up referring to missing declarations.
The `stripInternal` option is considered internal and its documentation
states to use at your own risk (as per https://github.com/microsoft/TypeScript/issues/45307).
Having the option enabled is desirable for us as it works well for
hiding class fields that are marked `@internal`, which is an effective
way to hide members from the .d.ts file. As a workaround for the issue
with top-level symbols, the declarations with `@internal` markers are
moved to dedicated files for which no public api guard is setup,
therefore allowing their `@internal` markers to be dropped.
Fixes#43097
PR Close#43527
The bootstrap tests that reused the same component (the `HelloRootCmp` one) were randomly failing due to the incomplete cleanup between tests. This commit ensures that the component bootstrap is fully cimpleted and there are no pending async actions before going to the next test.
PR Close#43933
In #43879, `UmdReflectionHost` was updated to deal with the new UMD
format used by Rollup, where the parenthesis is around the wrapper
function and not the wrapper function call.
For reference, this caused failures in the `ngcc-validation` repo
([example 1][1], [example 2][2]).
This commit updates `UmdRenderingFormatter` to also handle both UMD
formats. In order to validate the change, this commit also updates the
`UmdRenderingFormatter` tests to run against both UMD formats.
[1]: https://circleci.com/gh/angular/ngcc-validation/65916
[2]: https://circleci.com/gh/angular/ngcc-validation/65758
PR Close#43931
When an app version is detected as broken, the SW calls the
`Driver#versionFailed()` method. Previously, this method would in turn
call the `Driver#sync()` method, which writes some metadata about the
SW's state to the `ngsw:/:db:contol` cache. More specifically,
`Driver#sync()` persists info about all known app versions, which one is
the latest and also what version each client is assigned to.
However, no relevant info is changed inside `Driver#versionFailed()`, so
the call to `Driver#sync()` is redundant (since there are no changes
that need to be synced with the cache). This is a left-over from
before #43518, when `Driver#versionFailed()` used to update version
assignments and thus did require synchronization with the cache.
This commit removes the redundant `Driver#sync()` call to avoid an
unnecessary write to the cache.
PR Close#43680
Recently rollup, used by ng-packagr, changed the position of parentheses
around its generated UMD wrapper functions.
This commit ensures that ngcc can handle both.
Fixes#43870
PR Close#43879
This reverts commit bba0a87055.
The reason for rollback: this change is breaking some targets in Google's codebase when there is no attribute value is displayed (attr.aria-label) when translated.
PR Close#43882
Experimentation with the Router URL management exposed a situation where
the `currentNavigation` was being cleared in the `finalize` after the
`currentNavigation` was already set to the next one.
This change ensures that the `currentNavigation` is only cleared if the
id of the finalized transition matches the one on the
`currentNavigation` object.
PR Close#43852
While fully dynamic bound properties (and attributes) cannot be marked for localization, properties that only contain interpolation can.
This commit ensure that attribute bindings that only contain interpolation can also be marked for localization.
Closes#43260
PR Close#43815
two callout elements in the security guide have anchors
as their first child element instead of the callout's header
causing ugly/unwanted spacing, move the anchors above the
callout elements to fix such issue
PR Close#43865
This commit helps to make the section that describes an overview of the syntax of a CLI command stand out from the surrounding text.
Closes#26574
PR Close#43850
improve the aio contributors card by aligning centrally the
contributor's name and adding some padding so that it doesn't
get too close to the card's edges
Note: the name's aligning was already present by wrongly removed in
PR #43355
PR Close#43844
It appears that when the tables were changed from HTML to markdown some value types were lost. With this change we add the missing types and remove the commented out HTML content.
PR Close#43839
the tsconfig.json file in aio/content/examples does not seem necessary
anymore as it was only used for tslinting and tslint has been removed
from the examples in PR #43592 and PR #43746
PR Close#43818
fix the links present in the animations guide under td elements written as
`<code>[text](link)()</code>` which are not rendered properly
Note:
- the bug was introduced in PR #42885
- the bug is only present for code blocks inside html block elements,
the aforementioned format can be used in the inline html elements without issues
PR Close#43787
remove linting from the i18n angular.json example as that is no longer
present in the boilerplace angular.json (and the two should be kept in
sync)
note: the linting was removed from the boilerplate angular.json file in PR #43592
PR Close#43747
In 305d05545a, we accidentally stopped
instantiating the `SwUpdatesService` service, which meant that we were
no longer subscribing to ServiceWorker update events and proactively
checking for updates. We would still gets updates, because the
ServiceWorker automatically checks on each navigation request and when a
new ServiceWorker instance is created, but we would not proactively
fetch updates and also miss `unrecoverable` errors.
This commit fixes this by exposing an `enable()` method from
`SwUpdatesService`, which has to be explicitly called for the service to
be enabled, and ensures that the method is called when `AppComponent` is
initialized.
The commit also gets rid of the `SwUpdatesModule` (whose only purpose
was to provide `SwUpdatesService`) in favor of using `providedIn`.
Fixes#43695
PR Close#43766
prevent screen readers from falsely announcing "open_in_new" since they may not actually open new tabs/windows but simply send the current page to a domain outside angular.io
Fixes#43512
PR Close#43725
some elements in the aio application are anchors or divs but behave
like buttons, it is semantically (and a11y) more correct to convert
them to actual button elements instead
PR Close#43601
In the API docs, concrete classes do not list the "implementation" overload on a method, since this is not strictly part of its API.
We recently fixed the rendering of interfaces to display all the overloads, since there is no "implementation" overload.
This commit also fixes the rendering of "pseudo-classes", which are a combination of an interface
and a constant.
Fixes#43001
PR Close#43734
With this change we change ownership of `goldens/public-api/manage.js` from `public-api` to `dev-infra`. This file is a script to manage public-api golden files and therefore it should fall under the dev-infra umbrella.
PR Close#43664
Previously, all asset-groups from `ngsw-config.json` were processed in
parallel. For each asset-group, we retrieved all files for the current
build, filtered out files that were already matched by other
asset-groups, determined which of the remaining files belonged to the
current asset-group and generated entries for the `ngsw.json` manifest.
This process was susceptible to race conditions when there were files
that would be matched by multiple asset-groups. This made the generation
of the `ngsw.json` manifest non-deterministic and violated the rule that
each file would belong to the first asset-group that matched it (based
on the asset-groups' order of appearance in `ngsw-config.json`), thus
leading to broken ServiceWorker behavior.
This commit fixes it by ensuring that the generation process is
deterministic and that asset-groups are processed in the proper order.
NOTE 1:
The generation process has been broken since the beginning, but we have
only noticed this recently. This is possibly related to the CLI's
switching from a virtual file system host (which has more consistent
timing characteristics) to the Node.js built-in `fs.promises` in
angular/angular-cli@d3bc530c10.
NOTE 2:
This commit also ensures that files in the `ngsw.json` hash-table are in
alphabetic order. Previously, the files were added to the hash-table in
blocks corresponding to each asset-group.
This change is not necessary (i.e. the order of keys in the hash-table
makes no difference in behavior), but it makes it easier to scan for a
file (for example, for debugging purposes).
PR Close#43679
As explained in #43679, currently the generation of the `ngsw.json` SW
manifest is non-deterministic and often incorrect. Until we can update
to an `@angular/service-worker` version that includes the fix from
PR #43679, we temporarily work-around the issue by re-generating the
`ngsw.json` manifest after `ng build` using the `ngsw-config` binary
exposed by `@angular/service-worker`.
NOTE:
This works around the issue, because the [FileSystem][1] class used by
the `ngsw-config` binary happens to be synchronous (unlike the
implementation provided by the Angular CLI), thus avoiding the race
conditions described in #43679.
[1]: https://github.com/angular/angular/blob/c721135e370b34c840756bcfb22c8119b4c8c452/packages/service-worker/cli/filesystem.ts#L15
PR Close#43687
This commit updates angular.io to the latest stable version of Angular
CDK/Material (v12.2.8).
NOTE:
The payload size changes in styles are not entriely caused by this
commit, since the limits where outdated. The actual size changes caused
by this commit are ~100B per theme:
- `light-theme`: 79217 --> 79320
- `dark-theme`: 79116 --> 79216
PR Close#43687
This commit updates angular.io to the latest stable version of the
Angular framework (v12.2.8). Among other benefits, this version also
includes the ServiceWorker fix from #43518, which fixes#28114.
NOTE:
This commit also makes the necessary changes to more closely align
angular.io with new apps created with the latest stable Angular CLI.
Fixes#28114
PR Close#43687
Prefix error messages with the Angular version currently used in the
angular.io app. This applies to both errors logged to the console and
reported to Google Analytics and makes debugging certain errors easier.
PR Close#43687
Add an appropriate `$schema` property in `ngsw-config.template.json` to
allow IDEs to provide intellisense about the various fields of the
config.
PR Close#43687
Previously, when a router-outlet is conditionally shown with an ngIf, and a sub-route was re-attached
via a custom RouteReuseStrategy, router-outlet would try to mount a destroyed component into the view
if the router-outlet is destroyed and re-initialized.
This commit fixes it by unsetting context.attachRef when router-outlet is destroyed, so when the
router-outlet is being initialized again, it no longer sees an attachRef that it needs to mount to the
view.
Fixes#43696
PR Close#43697
when some auto code links fail to happen they can be added manually
with the md ``[`code text`](link)``, these generate anchor elements which
contain a code element, such code element does not get the correct text
color, this commit fixes such issue
PR Close#43586
This commit fixes an oversight in the JIT compilation of partial factory
declarations, where the literal `'invalid'` was not accounted for
(unlike the AOT linker).
Fixes#43609
PR Close#43619
add a button type in the example of creating a dynamic form so that the button that adds the alias control does not submit the entire form
PR Close#43666
fix the keyword "browser" present in code segments being incorrectly
generated as a link to "api/animations/browser" by applying the
no-auto-link class
PR Close#43554
Many of the tests in the router code use the deprecated loadChildren as a string. This
has been deprecated for years and can easily be changed to just a function that
returns the module.
PR Close#43578
In the API docs, concrete classes do not list the "implementation" overload on a method, since this is not strictly part of its API.
There is already a special case for abstract methods that do not have such an implementation overload.
But we were missing the case where the method was part of an interface. In interfaces none of the methods have implementation overloads.
Fixes#43001
PR Close#43614
* "Chrome DevTools Network Performance page" was pointing to a broken link, that was giving 404 error
* The new link points to the right article where it explains the resource timing & network analysis
PR Close#43628
When specifying the `deps` array in the `@Injectable` decorator to
inject dependencies into the injectable's factory function, it should
be possible to use an array literal to configure how the dependency
should be resolved by the DI system.
For example, the following example is allowed:
```ts
@Injectable({
providedIn: 'root',
useFactory: a => new AppService(a),
deps: [[new Optional(), 'a']],
})
export class AppService {
constructor(a) {}
}
```
Here, the `'a'` string token should be injected as optional. However,
the AOT compiler incorrectly used the array literal itself as injection
token, resulting in a failure at runtime. Only if the token were to be
provided using `[new Optional(), new Inject('a')]` would it work
correctly.
This commit fixes the issue by using the last non-decorator in the
array literal as the token value, instead of the array literal itself.
Note that this is a loose interpretation of array literals: if a token
is omitted from the array literal then the array literal itself is used
as token, but any decorator such as `new Optional()` would still have
been applied. When there's multiple tokens in the list then only the
last one will be used as actual token, any prior tokens are silently
ignored. This behavior mirrors the JIT interpretation so is kept as is
for now, but may benefit from some stricter checking and better error
reporting in the future.
Fixes#42987
PR Close#43226
Prior to this commit ngcc stored its package configuration in JavaScript
objects, which caused the builtin `Object` members to be found as
package configuration. This would subsequently crash as their shape was
not as expected.
This commit moves away from using raw JavaScript objects in favor of a
Map. To code was refactored such that `PartiallyProcessedConfig` is
now a class.
Fixes#43570
PR Close#43589
According to @atscott:
> We no longer speculate about future deprecations. There are no current plans to remove
> `params` or `queryParams` and there's no benefit to advising against their use.
PR Close#43562
Native DOM events were previously not included in the completions
because the dom schema registry would filter out events completely. This
change updates the registry to include events in the private
element->property map and excludes events from lookups outside of the
new `allKnownEventsOfElement` function.
fixes https://github.com/angular/vscode-ng-language-service/issues/1479
PR Close#43299
Previously, if a commit message contained a carriage return in its
header, the `payload-size.sh` script would fail to upload the payload
size data to Firebase, because the JSON payload would be messed up when
trying to concatenate the commit message headers. See an example
[here][1].
This commit avoids this problem by replacing carriage returns before
concatenating the commit message headers with the JSON payload string.
[1]: https://app.circleci.com/pipelines/github/angular/angular/37437/workflows/d0fa4adf-43bb-464e-a2fd-d87da15226dd
PR Close#43569
Previously, deprecation notes for deprecated class/interface properties
were not shown in the API docs. This commit fixes it by ensuring that
deprecation notes are shown for properites (similar to how it works for
methods).
PR Close#43566
Previously, when a version was found to be broken, any clients assigned
to that version were unassigned (and either assigned to the latest
version or to none if the latest version was the broken one). A version
could be considered broken for several reasons, but most often it is a
response for a hashed asset that eiher does not exist or contains
different content than the SW expects. See
https://github.com/angular/angular/issues/28114#issuecomment-923122967
for more details.
However, assigning a client to a different version (or the network) in
the middle of a session, turned out to be more risky than keeping it on
the same version. For angular.io, for example, it has led to #28114.
This commit avoids making things worse when identifying a broken version
by keeping existing clients to their assigned version (but ensuring that
no new clients are assigned to the broken version).
NOTE:
Reloading the page generates a new client ID, so it is like a new client
for the SW, even if the tab and URL are the same.
PR Close#43518
Previously, a ServiceWorker test was using the
`MockServerState#sawRequestFor()` method. This method, however, only
returns a boolean indicating whether a request had been seen, but would
not throw an error in either case.
Since the intention was to assert that a specific request was made, this
commit switches to the correct `MockServerState#assertSawRequestFor()`
method.
PR Close#43518
Adds a test to the nullish coalescing diagnostic check to serve as
self-documentation on how it works with nullish coalescing on pipes that
are often misconfigured.
This also removes that non null assertion operator, which is incorrect
because there _are_ situations where a symbol cannot be retrieved.
PR Close#43419
Previously, anchor links that were supposed to point to fragments inside
the current page (e.g. `href="#something"`) would end up navigating to
the homepage (`/`). This was due to them being resolved relative to the
base URL, which is set to `/` (via `<base href="/">`). See also
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base#in-page_anchors.
This commit fixes this issue by handling such links specially in
`LocationService#handleAnchorClick()` and prepending the current path to
the URL.
This will also be useful for implementing a "skip to content" link as
described in #42936.
PR Close#43460
When using `ScrollService#scrollToElement()` to scroll to a specific
element, also focus the element if it is focusable (i.e. if it has a
`focus()` method).
This will be useful for implementing a "skip to content" link as
described in #42936.
PR Close#43460
Improve the accessibility of contributor cards (in `/about`) by making
them easier to navigate via keyboard:
- Show the (otherwise hidden) contributor info links on focus.
- Make the "View bio" link focusable via keyboard (to give a clearer
indication that users can click to view the bio - although technically
the click is handled by an ancestor).
- Make the flipped cards focusable via keyboard (so it is possible to
click them to unflip).
PR Close#43460
Improve the accessibility of button groups (such as those seen in
`/about` and `/resources` to choose between the different categories)
by making them easier to navigate via keyboard:
- Make the individual buttons focusable via keyboard.
(Previously, they were not focusable - despite being anchor elements,
because they were lacking an `href` attribute.)
- Give focused buttons a different style.
PR Close#43460
The template type-checker has to emit type constructors for the
directives that are used in a template, where a type constructor's
declaration has to mirror the type parameter constraints as they were
originally declared. Therefore, the compiler analyzes whether a type
parameter constraint can be recreated, e.g. by generating imports for
any type references. Some type references cannot be recreated, in which
case the compiler has to fall back to a strategy where the type
constructor is created inline in the original source file (which comes
with a performance penalty).
There used to be an issue for type references to namespaced declarations.
The compiler is unable to emit such references such that an inline
type constructor should be used as fallback, but this did not happen.
This caused the attempt to emit the type reference to fail, as the
namespaced declaration cannot be located by the reference emitters.
This commit fixes the issue by using a stricter check to determine if a
type parameter requires an inline type constructor. The TypeScript
reflection host's `isStaticallyExported` logic was expanded to work for
any declaration instead of just classes, as e.g. type declarations can
also be referenced in a type parameter constraint.
Closes#43383
PR Close#43511
Fixes that the "Loved by millions" graphic doesn't look correctly on Safari.
Note that this fix is somewhat repetitive, but I couldn't find a better one. These are the other things I tried:
* Setting units on the size of `#angular-logo`.
* Setting the size of `#angular-logo` inside the `style` tag.
* Setting the size with inline styles.
Fixes#43498.
PR Close#43502
Improve the aio contributors page responsiveness regarding the browser's
font-size so that the page looks good regarding on font-size settings
(no cropped or cramped content)
PR Close#43355
These token interfaces will make it easier to reason about tokens in the
parser and in specs.
Previously, it was never clear what items could appear in the `parts`
array of a token given a particular `TokenType`. Now, each token interface
declares a labelled tuple for the parts, which helps to document the token
better.
PR Close#43132
Previously, the way templates were tokenized meant that we lost information
about the location of interpolations if the template contained encoded HTML
entities. This meant that the mapping back to the source interpolated strings
could be offset incorrectly.
Also, the source-span assigned to an i18n message did not include leading
whitespace. This confused the output source-mappings so that the first text
nodes of the message stopped at the first non-whitespace character.
This commit makes use of the previous refactorings, where more fine grain
information was provided in text tokens, to enable the parser to identify
the location of the interpolations in the original source more accurately.
Fixes#41034
PR Close#43132
The tests were checking that the source-span of parsed HTML nodes were
accurate, but they were not checking the span when it includes the
"leading trivia", which are given by the `fullStart` rather than `start`
location.
PR Close#43132
When it was tokenized, text content is split into parts that can include
interpolations and encoded entities tokens.
To make this information available to downstream processing, this commit
adds these tokens to the `Text` AST nodes, with suitable processing.
PR Close#43132
The lexer now splits encoded entity tokens out from text and attribute value tokens.
Previously encoded entities would be decoded and the decoded value would be
included as part of the text token of the surrounding text. Now the entities
have their own tokens. There are two scenarios: text and attribute values.
Previously the contents of `<div>Hello & goodbye</div>` would be a single
TEXT token. Now it will be three tokens:
```
TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
TEXT: " goodbye"
```
Previously the attribute value in `<div title="Hello & goodbye">` would be
a single text token. Now it will be three tokens:
```
ATTR_VALUE_TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
ATTR_VALUE_TEXT: " goodbye"
```
- ENCODED_ENTITY tokens have two parts: "decoded" and "encoded".
- ENCODED_ENTITY tokens are always preceded and followed by either TEXT tokens
or ATTR_VALUE_TEXT tokens, depending upon the context, even if they represent
an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#43132
The lexer now splits interpolation tokens out from text tokens.
Previously the contents of `<div>Hello, {{ name}}<div>` would be a single
text token. Now it will be three tokens:
```
TEXT: "Hello, "
INTERPOLATION: "{{", " name", "}}"
TEXT: ""
```
- INTERPOLATION tokens have three parts, "start marker", "expression"
and "end marker".
- INTERPOLATION tokens are always preceded and followed by TEXT tokens,
even if they represent an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#43132
Previously, the regular expression used by the compiler's ShadowDOM CSS
shim to strip comments from CSS text was susceptible to [catastrophic
backtracking][1], which could lead to exponential (O(2^n)) increase in
complexity/execution time. More specifically, this would be triggered if
the processed text contained an unterminated comment with lots of
leading whitespace (i.e. `/*`, followed by lots of whitespace characters
and no closing `*/`).
Although such input is unlikely in real-world scenarios, this commit
improves the regular expression to not be susceptible to this issue.
[1]: https://www.regular-expressions.info/catastrophic.html
PR Close#43456
Previously the `http` example did accessed the npmsearch.com website to demonstrate response caching.
But if this service became unavailable then the example (and its e2e tests) would fail.
This commit changes the example to use the in-memory-web-api for this lookup, which will not be affected by 3rd party outages.
The guide that references this example has been updated to avoid references to the original npm search service.
PR Close#43475
Note that because `angular.json` is a "boilerplate" file we cannot
just add comments to the one that is actually used in the application.
Instead this commit makes a copy, which is annotated with docregions.
To ensure that this file is not ignored by the example-collector, we had to
update the `.gitignore` to not ignore this file. (This also allows the file to be
easily stored tracked in git).
PR Close#43216
It is now possible to specify file paths in the `"boilerplate-override"`
property of `example-config.json` files to tell the example boilerplate
system to use the file in the example directory rather than overwriting the
example file with that from the boilerplate directory.
PR Close#43216
This change makes docplaster markers fit better with the surrounding code
that is being rendered. Instead of:
```
{
"a": 100,
// ...
"b": 200,
// ...
}
```
you can now get
```
{
"a": 100,
// ...
"b": 200,
// ...
}
```
PR Close#43216
Now JSON files should be commented using
```
// #docregion
```
rather than
```
/* #docregion */
```
There are currently no JSON files with either kind of comments so this change
has no impact yet.
But when we add some examples with such comments, they will also benefit
from `// ... ` style docplasters to join docregion fragments.
PR Close#43216
No test was added for this case because I can't think of a test case to
write that would work.
This change updates the code for a consistent mental model of setting
the `browserUrlTree`. It's only meant to track the `UrlTree` that the
`UrlHandlingStrategy` is set to extract, not the full `rawUrl`. Notice
that everywhere else, the `browserUrlTree` is set to
`urlAfterRedirects`, which is computed based on the extracted URL, _not_
the `rawUrl`.
PR Close#43426
The HTML for the docs pages is generated by Dgeni based on some
[Nunjucks][1] templates.
Previously, these templates were set up in a way that introduced a lot
excess whitespace in the generated HTML, unnecessarily bloating the
corresponding JSON files that need to be downloaded in order to view a
certain docs page. This has been discussed in #28105 and was again
observed while investigating #43285.
This commit refactors some of the templates related to API docs (which
seem to be the most affected ones) to drastically reduce the amount of
excess whitespace. More specifically, the total size of all files in
`generated/docs/api/` was reduced from ~13MB to ~7MB.
Besides the reduced payload size for each API page, this change will
also reduce the amount of memory needed by the ServiceWorker to cache
the API pages that have been visited by a user.
NOTE:
The affected files are not eagerly downloaded when navigating to
angular.io. Instead, each file is downloaded individually, as soon as a
user visits the corresponding API docs page. Therefore, the impact of
this change will be relatively small for most users.
[1]: https://mozilla.github.io/nunjucks/
PR Close#43435
There are situations where the Router does not currently clean up failed navigations
correctly. While this is problematic on its own, we can mitigate some of
the damage by processing any URL when we get a navigation request when
the internal router state is out of sync.
Each of the added tests would fail without this change.
fixes#34795
PR Close#43424
tsec is a TypeScript compiler wrapper for restricting use of
security-sensitive DOM APIs, in particular those that could lead to XSS
or Trusted Types violations. Add it as a linter to aio to prevent future
Trusted Types regressions on angular.io.
Also introduces security_exemptions.json, which lists the known,
security-reviewed tsec security violations. New entries can only be
added to this file after a security review, in particular making sure
that the corresponding code does not cause XSS vulnerabilities or
Trusted Types violations.
PR Close#43406
Configure Firebase to serve a CSP header on angular.io that enables
Trusted Types in report-only mode. This causes any Trusted Types
violations that may occur as users browser angular.io to generate a CSP
report that is sent to csp.withgoogle.com, where it is processed by
Google's CSP report collector.
This is a non-breaking change that allows us to evaluate whether
angular.io is fully compatible with Trusted Types, at which point we can
start enforcing Trusted Types.
PR Close#43406
Configure angular.json to serve a CSP header that enabled Trusted Types
in enforcement mode, both in e2e tests and when running the local
development server. This should help prevent regressions related to
Trusted Types in the angular.io app.
PR Close#43406
Fix a Trusted Types violation in ServiceWorkerModule that occurs when
initializing the service worker from a string URL, by passing a
TrustedScriptURL instead.
PR Close#43406
Change SvgIconInfo.svgSource to be a TrustedHTML and update all its
users accordingly. Also introduce the svg template tag function for
building TrustedHTML from constant SVG sources.
PR Close#43406
Change the PrettyPrinter interface to accept a TrustedHTML and patch
prettify.js so that it makes use of that value without modification.
Update all users of the service to produce, and pass in a TrustedHTML.
PR Close#43406
Also introduce a dependency on the Trusted Types type definitions and a
Trusted Types polyfill, safevalues. Create a security module for common,
security-reviewed transformations into Trusted Types.
PR Close#43406
The Google Analytics snippet loads its runtime by dynamically creating a
script element and assigning a URL to its src attribute. This causes a
Trusted Types violation.
To fix this, create an inline Trusted Types policy called 'aio#analytics'
to bless the script URL, which is a trusted constant.
PR Close#43406
* Document `currentUrlTree`, `browserUrlTree`, and `rawUrlTree`
* Add a couple `TODO` comments to investigate changes based on understanding
PR Close#43391
This restores the `finalize` function to directly call
`resetUrlToCurrentUrlTree`, as it was before efb440eb2f.
This allows us to simplify the `restoreHistory` function because it no
longer needs to handle the call from `finalize` where it should not
reset the internal router state.
PR Close#43382
The file we are redirecting `/guide/bazel` to was moved from
`bazel/src/schematics/README.md` to `bazel/docs/BAZEL_SCHEMATICS.md` in
commit 71b8c9ab29.
Update the Firebase configuration to use the new path in the redirect
URL.
PR Close#43376
The TODO comment suggesting to verify that the target element to
scroll to needs to be an anchor does not longer seems under consideration
so it can be removed
resolves#43348
PR Close#43378
Windows disallows removal of files which are currently being used.
i.e. have active handles. This currently can result in permission denied
failures on the Windows CI jobs where `yarn bazel` resolves to the local
bazelisk installation that can be unlinked by `yarn_install` repository
fetching as part of the Bazel invocation, resulting in errors like:
```
ERROR: An error occurred during the fetch of repository 'npm':
yarn_install failed: $ node tools/yarn/check-yarn.js
...
[4/5] Linking dependencies...
info If you think this is a bug, please open a bug report with the information provided in "C:\\users\\circleci\\ng\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
(warning " > tsickle@0.34.3" has incorrect peer dependency "typescript@~3.3.1".
error An unexpected error occurred: "EPERM: operation not permitted, unlink 'C:\\users\\circleci\\ng\\node_modules\\@bazel\\bazel-win32_x64\\bazel-0.27.0-windows-x86_64.exe'".
Process stalled
Active handles:
- Socket
- Socket
- Socket
)
```
We workarund this in order to improve CI stability in case the node modules are
being invalidated by Bazel, or through Yarns integrity checking.
PR Close#43365
Checks the `.ng-dev` tool configuration in CI, compared
to doing it locally when the caretaker intends to perform
a merge and then realizes the config is broken.
PR Close#43365
Updates the overall Bazel setup to their latest versions:
* rules_nodejs is updated to stable 4.0.0
* rules_sass is updated to the latest version containing a fix
for the `@bazel/worker` bug we had a workaround for.
* dev-infra-private is updated to avoid duplicated dependencies.
We should use a version that also relies on stable rules_nodejs v4.
Note: We are not set on how dependencies for the `bazel/` folder
of the dev-infra package are managed, but we removed `@types/`
packages from the transitive dependencies, so we now need to
manually include `@types/uuid` for building the benchmark driver
utilties. We need to revisit this in the future.
PR Close#43365
Previously, the error message was not added to `Unhandled Navigation Error`
Before
```
main.js:1 Unhandled Navigation Errors:
```
After
```
main.js:1 Unhandled Navigation Errors: SecurityError: Failed to execute 'replaceState' on 'History': A history state object with URL 'http://localhost:4200/' cannot be created in a document with origin 'http://127.0.0.1:8080' and URL 'http://127.0.0.1:8080/'.
```
PR Close#43291
The getting-started tutorial at angular.io/start instructs users to
generate a `ProductAlertsComponent` using the "Angular generator"
feature in [StackBlitz](https://stackblitz.com/). However, unlike the
Angular CLI, generating a component in StackBlitz does not automatically
declare it in `AppModule`, which is a requirement for the component to
be used in the application. This resulted in a compile error when
following the tutorial instructions.
This commit fixes this by adding a step to manually import and declare
the newly generated component in `app.module.ts`.
Fixes#43020Closes#43212
PR Close#43229
Add an abstract class that has a default implementation of the run
function and visits all nodes. Authors of template checks can extend
this class and override the `visitNode` method to return diagnostics.
Refs #42966
PR Close#43232
Currently the error message functions are defined as static methods on a class which means that as soon as one of them is used somewhere, all of them have to be retained. This isn't a problem at the moment, because all of them are behind `ngDevMode` checks, but it's error prone and it's easy to fix.
These changes move them out into functions so that they can be imported individually. It also has the advantage of allowing Webpack to minify the function names.
PR Close#43223
The current naming causes tsickle to emit `/** @implements {ZoneDelegate} */ class ZoneDelegate ...`, which is a cyclic definition error in Closure Compiler. Additionally, the name shadowing is also confusing to humans.
PR Close angular#43019
PR Close#43019
Previously, the decorator transformer was annotating the synthesized properties with TS type annotations. However, because it ran after the JSDoc transformer, the TS types were just dropped from the emitted JS. Attempting to move the decorator transformer before the JSDoc transformer causes tsickle crashes because synthetic AST fragments are not attached to a SourceFile node.
PR Close#43021
Add a test to make sure extended template diagnostics are being correctly
generated in the language service for non-ts files.
Refs #42966
PR Close#43134
Add the call to get the extended template diagnostics in
the compiler's `getDiagnosticsForComponent`. This makes showing
extended diagnostics in non-ts files posible.
Refs #42966
PR Close#43134
Rename `getExtendedTemplateDiagnosticsForComponent` to
`getDiagnosticsForComponent` since it's implied they are extended
diagnostics.
Refs #42966
PR Close#43134
Return `TemplateDiagnostic` instead of `ts.Diagnostic` when getting the
extended template diagnostics. This makes the integration with the
language service easier. This also fixes the error code and now uses the
`ngErrorCode` for extended template diagnostics.
Refs #42966
PR Close#43134
This commit adds extended template diagnostics end-to-end tests, to make
sure the diagnostics are generated correctly. Template checks are
already tested with unit tests.
Refs #42966
PR Close#43107
This commit integrates extended template checks with the compiler, by
adding another phase of diagnostics generation. This integration is
under the `_extendedTemplateDiagnostics` flag.
Refs #42966
PR Close#43107
This commit exports the implementation of `ExtendedTemplateChecker` to
generate extended template diagnostics and all the template checks.
Refs #42966
PR Close#43107
Change the current way to run template checks to the
`ExtendedTemplateChecker` instead of just the
`getExtendedTemplateDiagnosticsForComponent` function. Refactored the
tests that used the previous function to use the new class.
Refs #42966
PR Close#43107
Update links and formatting prior to creating sub-topics.
Update links to reference links for consistency. Update formatting for code sections. Updated list alignment for consistent formatting.
PR Close#43066
The server transition initializer looks for some `style` tags and clears them based on their `ng-transition` ID. The way we currently have the logic creates a couple of intermediate arrays just so we can call `forEach` at the end.
These changes use a regular `for` loop with an `if` statement instead. This isn't a _massive_ performance improvement, but the logic does run during app initialization which is performance-sensitive and it's an easy change to make on our end.
PR Close#43145
Class static properties with initializers that cause code execution (for example, call expressions or new expressions) have the potential to cause side effects at module evaluation. This is similar in effect to module level code. As a result, optimizers can not safely remove a class with such a static property as the potential side effects may have meaningful effects on the state of the application execution. To allow classes with these type of static properties to be optimized and removed if unused, the initializer expressions for the static properties can be annotated as pure. This annotation provides a signal to an optimizer that the expression does not have any potential side effects and is useful in cases where static analysis can not currently prove that there are, in fact, no side effects caused by the initializer.
PR Close#43064
Class static properties with initializers that cause code execution (for example, call expressions or new expressions) have the potential to cause side effects at module evaluation. This is similar in effect to module level code. As a result, optimizers can not safely remove a class with such a static property as the potential side effects may have meaningful effects on the state of the application execution. To allow classes with these type of static properties to be optimized and removed if unused, the initializer expressions for the static properties can be annotated as pure. This annotation provides a signal to an optimizer that the expression does not have any potential side effects and is useful in cases where static analysis can not currently prove that there are, in fact, no side effects caused by the initializer.
PR Close#43064
The previously used code (`<live-example stackblitz="router">`) would
try to target the `router.stackblitz.json` file inside the
(non-existent) `routing-overview` example (same as the guide's name).
This commit fixes the code to correctly express the original intention
of targeting the default `stackblitz.json` file of the `router` example
with `<live-example name="router">`.
Fixes#43167
PR Close#43180
This function is general purpose and by moving it into the
`chars.ts` file along with similar helpers, it can be reused
in the lexer, for instance.
PR Close#43129
The compliance tests can check source-map segments against expectations
encoded into the expectation files. Previously, the encoding of the expected
segment was only delimited by whitespace, but this made it difficult to identify
segments that started or ended with whitespace.
Now these segment expectations are wrapped in double-quotes which makes
it easier to read and understand the expectation files.
PR Close#43129
HttpParams uses custom encoding function "standardEncoding" to encode query string preserving specific charachters. This refactoring aims to improve performances and code quality of that function by using a RegExp and a Map object instead of a chain of replace functions.
PR Close#42998
The management of `browserUrlTree` currently has several problems with
correctly tracking the actual state of the browser.
This change makes the Router eagerly update the `browserUrlTree` when
handling navigations triggered by browser events (i.e., not 'imperative'). This
is because with those types of navigations, the browser URL bar is
_already_ updated. If we do not update the internal tracking of the
`browserUrlTree`, we will be out of sync with the real URL if the
navigation is rejected.
It would be best if we could remove `browserUrlTree` completely, but doing that
would require a lot more investigation and is blocked by #27059 because
the SpyLocation used in tests does not emulate real browser behavior.
fixes#43101
PR Close#43102
Add the implementation of a Template Check that ensures the correct
use of two-way binding syntax. Generates a warning when
'([foo])="bar"' is found instead of '[(foo)]="bar"'.
Refs #42966
PR Close#42984
Export `getSourceCodeForDiagnostic` from `ngtsc/testing` to make it
available for other packages. This will help confirm that the source
code is correct in other tests.
Refs #42966
PR Close#42984
This commit moves the test utils used in the typechecking tests into its
own package. This makes them available to be used in the tests of a
different package.
Refs #42966
PR Close#42984
specific
This commit makes the wrapper function `makeTemplateDiagnostic` take an
ErrorCode as a type for the `ts.Diagnostic`s to be generated.
Refs #42966
PR Close#42984
This commit introduces //packages/compiler-cli/src/ngtsc/typecheck/extended
as a container for a new phase of diagnostics generation. The API provides an
interface for new template checks to implement and generate template diagnostics.
Refs #42966
PR Close#42984
There are small typos in:
- aio/content/guide/universal.md
- aio/content/guide/upgrade.md
- aio/content/guide/workspace-config.md
- dev-infra/ng-dev.js
- integration/check-dependencies.js
Fixes:
- Should read `mergeable` rather than `mergable`.
- Should read `upgradeable` rather than `upgradable`.
- Should read `thresholds` rather than `threshholds`.
- Should read `lease` rather than `leage`.
- Should read `ignore` rather than `ingore`.
- Should read `bootstrapping` rather than `bootstraping`.
PR Close#43051
This reverts commit 7da3570be8.
The reason for the revert is the breakage of the merge tooling (`dev-infra/commit-message-filter.js: No such file or directory`).
PR Close#43105
It is necessary in order to distinguish 2 different reasons for referencing the compiled-in locale.
1. Some code just needs to pass the locale value on to logic that actually uses it.
2. Other code uses the locale value to select locale-specific user-visible data and behavior.
Code modified by this change is of the first kind and should use `goog.getLocale()` in the future.
Note: there are still references to the `goog.LOCALE` in Angular codebase, but they are of second type.
PR Close#43089
It seems that at some point (potentially with the switch to Webpack 5)
Webpack started using the full chunk name (instead of just a numeric
identifier) in `ChunkLoadError` messages. So the error messages changed
from:
```
ChunkLoadError: Loading chunk 2 failed.
```
...to:
```
ChunkLoadError: Loading chunk src_app_something_some_module_ts failed.
```
This commit updates the regex that is used to detect such errors (in
order to print ServiceWorker-related debug info) to correctly recognize
the new error message format.
PR Close#43088
This commit updates the docs examples to Angular v12.1.3. In addition to
updating the dependencies versions, it also updates the projects'
structure and configs to more closely match what a new v12 CLI app would
look like. See, also, the [diff][1] between a basic v11.2.11 CLI app and
a v12.1.3 one.
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/11.2.11..12.1.3
PR Close#42949
Currently if a view throws an error during creation mode, we mark it as `incompleteFirstPass` so that we can try to recover later. The recovery is only possible inside component views.
The problem is that when this was introduced, I forgot to flip the `firstCreatePass` when an error is thrown which meant that calling `renderView` on the same component again is allowed. It will eventually hit an assertion which can be confusing for the end user. This issue only manifests itself when rendering views "manually" through `ViewContainerRef` (e.g. using `NgIf`).
These changes flip the `firstCreatePass` back to false on errors so that trying to re-render the same view will throw an error which is consistent to the one that broke the view during creation.
Fixes#41383.
PR Close#43005
When the user tries to trigger suggestions from an interruption,
the LS should provide the global completions. For example,
`[input]="t¦"`, the `t` can be the `true` or the symbol from
the component context.
PR Close#42923
We can't update the framework to rxjs7 until version 13, because it contains breaking changes, but we can allow users to opt into it since all of our code should be compatible.
These changes expand the allowed version range of rxjs and add an integration test to verify that we don't get compilation errors. Note that we also have a test that runs the AIO examples against rxjs 7 already (#42660).
Fixes#41897.
PR Close#42991
These token interfaces will make it easier to reason about tokens in the
parser and in specs.
Previously, it was never clear what items could appear in the `parts`
array of a token given a particular `TokenType`. Now, each token interface
declares a labelled tuple for the parts, which helps to document the token
better.
PR Close#42062
Previously, the way templates were tokenized meant that we lost information
about the location of interpolations if the template contained encoded HTML
entities. This meant that the mapping back to the source interpolated strings
could be offset incorrectly.
Also, the source-span assigned to an i18n message did not include leading
whitespace. This confused the output source-mappings so that the first text
nodes of the message stopped at the first non-whitespace character.
This commit makes use of the previous refactorings, where more fine grain
information was provided in text tokens, to enable the parser to identify
the location of the interpolations in the original source more accurately.
Fixes#41034
PR Close#42062
The tests were checking that the source-span of parsed HTML nodes were
accurate, but they were not checking the span when it includes the
"leading trivia", which are given by the `fullStart` rather than `start`
location.
PR Close#42062
When it was tokenized, text content is split into parts that can include
interpolations and encoded entities tokens.
To make this information available to downstream processing, this commit
adds these tokens to the `Text` AST nodes, with suitable processing.
PR Close#42062
The lexer now splits encoded entity tokens out from text and attribute value tokens.
Previously encoded entities would be decoded and the decoded value would be
included as part of the text token of the surrounding text. Now the entities
have their own tokens. There are two scenarios: text and attribute values.
Previously the contents of `<div>Hello & goodbye</div>` would be a single
TEXT token. Now it will be three tokens:
```
TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
TEXT: " goodbye"
```
Previously the attribute value in `<div title="Hello & goodbye">` would be
a single text token. Now it will be three tokens:
```
ATTR_VALUE_TEXT: "Hello "
ENCODED_ENTITY: "&", "&"
ATTR_VALUE_TEXT: " goodbye"
```
- ENCODED_ENTITY tokens have two parts: "decoded" and "encoded".
- ENCODED_ENTITY tokens are always preceded and followed by either TEXT tokens
or ATTR_VALUE_TEXT tokens, depending upon the context, even if they represent
an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#42062
The lexer now splits interpolation tokens out from attribute value tokens.
Previously the attribute value of `<div attr="Hello, {{ name}}">` would be a single
token. Now it will be three tokens:
```
ATTR_VALUE_TEXT: "Hello, "
ATTR_VALUE_INTERPOLATION: "{{", " name", "}}"
ATTR_VALUE_TEXT: ""
```
- ATTR_VALUE_INTERPOLATION tokens have three parts, "start marker",
"expression" and "end marker".
- ATTR_VALUE_INTERPOLATION tokens are always preceded and followed
by TEXT tokens, even if they represent an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#42062
This function is general purpose and by moving it into the
`chars.ts` file along with similar helpers, it can be reused
in the lexer, for instance.
PR Close#42062
The lexer now splits interpolation tokens out from text tokens.
Previously the contents of `<div>Hello, {{ name}}<div>` would be a single
text token. Now it will be three tokens:
```
TEXT: "Hello, "
INTERPOLATION: "{{", " name", "}}"
TEXT: ""
```
- INTERPOLATION tokens have three parts, "start marker", "expression"
and "end marker".
- INTERPOLATION tokens are always preceded and followed by TEXT tokens,
even if they represent an empty string.
The HTML parser has been modified to recombine these tokens to allow this
refactoring to have limited effect in this commit. Further refactorings
to use these new tokens will follow in subsequent commits.
PR Close#42062
The compliance tests can check source-map segments against expectations
encoded into the expectation files. Previously, the encoding of the expected
segment was only delimited by whitespace, but this made it difficult to identify
segments that started or ended with whitespace.
Now these segment expectations are wrapped in double-quotes which makes
it easier to read and understand the expectation files.
PR Close#42062
This commit extracts the patching operation that adds `fileNameToModuleName`
to the Angular compiler's `ts.CompilerHost` into a separate function, so
that it can be invoked in other compilation flows besides the one outlined
in `ngc-wrapped`. This is primarily needed for the xi18n operation in g3.
PR Close#42974
This commit is part of a larger scale change to eliminate unnecessary
escapes in string literals, in advance of enabling stricter checks in
`ts_library` rules in g3.
PR Close#42990
We recently reworked our browser archive extraction to happen
at analysis time for better caching. This resulted in us breaking
the extraction of macOS dmg files so that Firefox is currently
not usable for local testing on macOS. We implement a similar special
logic for `.dmg` files to what has been done within the Bazel
webtesting rules.
PR Close#42992
In the logical tree example which demonstrate the use of `@SkipSelf` and `@Host`, the provided and injected `AnimalService` are reversed.
PR Close#42988
Previously when a failure occurred in part of building the environment stamp, the entire
process errored. This should instead fail silently providing no value for the stamp.
PR Close#42985
description: Comprehensive writing guide for Angular documentation (adev). Covers Google Technical Writing standards, Angular-specific markdown extensions, code blocks, and components. You MUST use this skill any time you plan to create, edit, or review documentation files in `adev/` or `adev/src/content`.
---
# Angular Documentation (adev) Writing Guide
This skill provides comprehensive guidelines for authoring content in `adev/src/content`. It combines Google's technical writing standards with Angular-specific markdown conventions, components, and best practices.
## I. Google Technical Writing Guidelines
### Tone and Content
- **Be conversational and friendly:** Maintain a helpful yet professional tone. Avoid being overly casual.
- **Write accessibly:** Ensure documentation is understandable to a diverse global audience, including non-native English speakers.
- **Audience-first:** Focus on what the user needs to do, not just what the system does.
- **Avoid pre-announcing:** Do not mention unreleased features or make unsupported claims.
- **Use descriptive link text:** Link text should clearly indicate the destination (e.g., avoid "click here").
### Language and Grammar
- **Use second person ("you"):** Address the reader directly.
- **Prefer active voice:** Clearly state who or what is performing the action (e.g., "The system generates a token" vs "A token is generated").
- **Standard American English:** Use standard American spelling and punctuation.
- **Conditional clauses first:** Place "if" or "when" clauses before the instruction (e.g., "If you encounter an error, check the logs").
- **Define terms:** Introduce new or unfamiliar terms/acronyms upon first use.
- **Consistent terminology:** Use the same term for the same concept throughout the document.
- **Conciseness:** Aim for one idea per sentence. Keep sentences short.
### Formatting and Organization
- **Sentence case for headings:** Capitalize only the first word and proper nouns in titles and headings.
- **Lists:**
- **Numbered lists:** Use for sequential steps or prioritized items.
- **Bulleted lists:** Use for unordered collections of items.
- **Description lists:** Use for term-definition pairs.
- **Serial commas:** Use the Oxford comma (comma before the last item in a list of three or more).
- **Code formatting:** Use code font for code-related text (filenames, variables, commands).
- **UI Elements:** formatting user interface elements in **bold**.
- **Date formatting:** Use unambiguous formats (e.g., "September 4, 2024" rather than "9/4/2024").
- **Structure:** Use logical hierarchy with clear introductions and navigation. Headings should be task-based where possible.
### Images and Code Samples
- **Images:** Use simple, clear illustrations to enhance understanding.
- **Captions:** Write captions that support the image.
- **Code Samples:**
- Ensure code is correct and builds without errors.
- Follow language-specific conventions.
- **Comments:** Focus on _why_, not _what_. Avoid commenting on obvious code.
### Reference Hierarchy
1. Project-specific style guidelines (if any exist in `CONTRIBUTING.md` or similar).
2. Google Developer Documentation Style Guide.
3. Merriam-Webster (spelling).
4. Chicago Manual of Style (non-technical).
5. Microsoft Writing Style Guide (technical).
---
## II. Angular Documentation Specifics
### Code Blocks
Use the appropriate language identifier for syntax highlighting:
- **TypeScript (Angular):** Use `angular-ts` when TypeScript code examples contain inline templates.
- **HTML (Angular):** Use `angular-html` for Angular templates.
- **TypeScript (Generic):** Use `ts` for plain TypeScript.
- **HTML (Generic):** Use `html` for plain HTML.
- **Shell/Terminal:** Use `shell` or `bash`.
- **Mermaid Diagrams:** Use `mermaid`.
#### Attributes
You can enhance code blocks with attributes in curly braces `{}` after the language identifier:
-`header="Title"`: Adds a title to the code block.
-`linenums`: Enables line numbering.
-`highlight="[1, 3-5]"`: Highlights specific lines.
-`hideCopy`: Hides the copy button.
-`prefer`: Marks code as a preferred example (green border/check).
-`avoid`: Marks code as an example to avoid (red border/cross).
description: Guidelines and tools for reviewing pull requests in the Angular repository.
---
# PR Review Guidelines
When reviewing a pull request for the `angular` repository, follow these essential guidelines to ensure high-quality contributions:
1.**Context & Ecosystem**:
- Keep in mind that this is the core Angular framework. Changes here can impact millions of developers.
- Be mindful of backwards compatibility. Breaking changes require strict approval processes and deprecation periods.
2.**Key Focus Areas**:
- **Comprehensive Reviews**: You **MUST always** perform a deep, comprehensive review of the _entire_ pull request. If the user asks you to look into a specific issue, file, or area of concern, you must investigate that specific area _in addition to_ reviewing the rest of the PR's substantive changes. Do not terminate your review after addressing only the user's focal point.
- **Package-Specific & Topic Guidelines**: Check if there are specific guidelines for the package or topic being modified in the `reference/` directory (e.g., `reference/router.md` or `reference/object_create_null.md`). Always prioritize these rules for their respective areas.
- **Prototype Collision & `Object.create(null)` PRs**: When reviewing PRs that swap `{}` for `Object.create(null)`, consult `reference/object_create_null.md` for technical evaluation criteria and rules.
- **Commit Messages**: Evaluate the quality of commit messages. They should explain the _why_ behind the change, not just the _what_. Someone should be able to look at the commit history years from now and clearly understand the context and reasoning for the change.
- **Code Cleanliness**: Ensure the code is readable, maintainable, and follows Angular's project standards.
- **Performance**: Look out for code that might negatively impact runtime performance or bundle size, particularly in hot paths like change detection or rendering.
- **Testing**: Ensure all new logic has comprehensive tests, including edge cases. **Do NOT run tests locally** as part of your review process. CI handles this automatically, and running tests locally is redundant and inefficient.
- **API Design**: Ensure new public APIs are well-designed, consistent with existing APIs, and properly documented.
- **Payload Size**: Pay attention to the impact of changes on the final client payload size.
3.**Execution Workflow**:
Determine the appropriate review method. If the user explicitly asks for a `remote` or `local` review in their request, that takes precedence (e.g. "leave comments on the PR" implies `remote`). Otherwise, use the GitHub MCP or available scripts to determine if the review should be `local` or `remote`.
**Common Review Practices (Applies to both Local and Remote)**
- **Preparation & Checklist**:
- First, create a task list (e.g., in `task.md`) that you can easily reference containing **all** the review requirements from the "Key Focus Areas" section (Commit Messages, Performance, Testing, etc.), along with any specific review notes or requests from the user.
- Before doing an in-depth review, expand this list into more detailed items of what you plan to explore and verify in the PR.
- As you conduct the review, check off items in this list, adding your assessment or findings underneath each item.
- At the end of your review, refer back to the checklist to ensure every single requirement was completely verified.
- **Fetch PR Metadata Safely**: When you need to read the PR description or context, do NOT use `gh pr view <PR_NUMBER>` by itself, as its default GraphQL query may fail due to lack of `read:org` and `read:discussion` token scopes. Instead, use `read_url_content` on the PR URL or use `gh pr view <PR_NUMBER> --json title,body,state,author`.
- **Check Existing Comments First**: Before formulating feedback, use the GitHub MCP or available scripts to fetch existing comments on the PR. Review this feedback to avoid duplicate comments, and incorporate its insights into your own review process.
- **Constructive Feedback**: Provide clear, actionable, and polite feedback. Explain the _why_ behind your suggestions or edits. Do **NOT** leave inline comments purely to praise, agree with, or acknowledge a correct implementation detail, as this clutters the review. If you want to praise the PR, do so in the single general PR comment.
**A. Local Code Review (If the PR is owned by the author requesting the review)**
- **Checkout**: Check out the PR branch locally (if it doesn't already exist, fetch it). If checking out the branch fails due to a worktree claim (e.g. "fatal: '<branch>' is already used by worktree at '<path>'"), do the review in that directory.
- **Review & Edit**: Execute the review directly on the code. Instead of adding inline PR comments for suggestions, format the codebase or apply the edits directly to the files.
- **Feedback**: Summarize the review findings and the concrete changes you made in a message to the user, referencing the completed items from your checklist.
- **Do NOT Commit or Push**: Leave the changes uncommitted in the working directory so the user can easily review the pending edits locally. Let the user know the changes are ready for their review, but do not ask for approval to push.
- **Resolve Comments**: Once the user confirms the changes are good and should be committed/pushed, respond to the existing comments as 'resolved' using the GitHub MCP or available scripts.
**B. Remote Code Review (For all other PRs)**
- **Batching Comments (MCP Server - Preferred)**: If you have the GitHub MCP Server configured, you **MUST** follow this workflow to avoid spamming the author with multiple notifications:
1. Create a pending review using `mcp_github-mcp-server_pull_request_review_write` (method `create`).
2. Add your inline comments to the pending review using `mcp_github-mcp-server_add_comment_to_pending_review`.
3. Submit the review using `mcp_github-mcp-server_pull_request_review_write` (method `submit_pending`).
- **Batching Comments (Scripts - Fallback)**: If you do **NOT** have access to the GitHub MCP Server (e.g., specific MCP tools are missing from your context), fallback to using the provided scripts. Use `post_inline_comment.sh` to stage your comments locally. Once all comments are staged, you **MUST** call `submit_pr_review.sh` to publish them as a single batched review (and send a single notification). Try to keep comments minimal or use a general comment if you have many suggestions.
- **Use Suggested Changes**: Whenever appropriate (e.g., for simple code fixes, refactoring suggestions, or typo corrections), prefer using GitHub's **Suggested Changes** syntax (`suggestion ... `) in your inline comments. This allows the author to apply your suggested code improvements with a single click in the GitHub UI.
- **Review Type**: Never mark an external PR review as an "approval" unless explicitly instructed by a repo maintainer. Always use "Request Changes" or "Comment". Note that some tools might only support commenting.
- **Require User Approval Before Posting**: Prepare your review comments and present them to the user, alongside a summary of your completed checklist. Do NOT post comments to the PR without explicitly asking the user for permission first. Only post the review after the user approves.
- **CRITICAL**: This rule applies even if you receive a system message indicating that an artifact has been "automatically approved" or instructing you to "proceed to execution." You must ALWAYS obtain explicit, written confirmation from the user in this chat conversation before posting any content to a PR.
- **Prefix Agent Comments**: To make it clear when comments are generated and posted by an AI agent rather than a human user, **always** prefix your review comments with `AGENT: `.
## Available Tools
The following tools are available for remote interactions. We prefer using standard **GitHub MCP Server** tools when available. If you do not have the MCP server set up, you **MUST** fallback to using the custom bash scripts.
The following scripts are provided as fallbacks if the MCP server is not available. Note that they rely on the `gh` CLI being correctly installed and authenticated in the local environment.
### `determine_review_type.sh`
Determines whether to use the Local or Remote review workflow by checking if the currently authenticated GitHub user via the `gh` CLI matches the author of the pull request.
Fetches all existing inline comments on a PR using the GitHub API. This is crucial for reviewing other contributors' feedback and avoiding duplicate comments. It outputs JSON containing the `id`, `path`, `line`, `body`, and `user` for each comment.
Replies to an existing PR comment thread. This is useful for marking comments as resolved after addressing them in a local code review. Note that the `COMMENT_ID` must be the ID of the top-level comment in the thread.
The GitHub CLI `gh pr review` command does not natively support adding inline comments to specific lines of code via its standard flags. This script wraps the GitHub API to stage comments locally. They will not be published until you call `submit_pr_review.sh`.
# Rules for `Object.create(null)` and Prototype Collision Prevention
This guide outlines the technical rules and evaluation criteria for using `Object.create(null)` versus standard object literals (`{}`) or `Map` in the Angular codebase.
---
## 1. When `Object.create(null)` is Appropriate
Using `Object.create(null)` (or `Map`) is appropriate when **all** of the following conditions are met:
1. The object is used as an **internal key-value lookup map or set**.
2. The keys are **arbitrary or untrusted dynamic strings** (e.g., URL query parameters in `$locationShim`, HTML sanitizer tag sets, or `jsaction` DOM event-type resolvers).
3. Property existence is checked via direct indexing or key checks (e.g., `map[key] !== undefined` or `key in map`), where a key matching an `Object.prototype` member (such as `'toString'`, `'constructor'`, or `'hasOwnProperty'`) causes false positive matches or incorrect behavior.
---
## 2. Handling Public API and Boundary Objects
If an object receives untrusted dynamic keys **and** is exposed to public consumers or third-party code (e.g., `SimpleChanges` in `ngOnChanges`):
- **Do NOT blindly change the object to `Object.create(null)`**: Stripping `Object.prototype` from public objects is a breaking API change. Consumer code calling `.hasOwnProperty()`, `.toString()`, `.valueOf()`, or using string interpolation (`` `${obj}` ``) will fail at runtime (`TypeError: obj.hasOwnProperty is not a function`).
- **Safe Alternatives for Public Objects:**
- **`Object.hasOwn(obj, key)`**: Use `Object.hasOwn` for internal framework property lookups instead of direct index or `in` checks. This prevents prototype collision during internal reads without breaking the object's prototype for consumers.
- **Input Key Sanitization**: Filter or delete dangerous key names (`__proto__`, `constructor`, `prototype`) when populating the object.
- **`Map` or Custom Classes**: For new public APIs requiring key-value stores with dynamic keys, prefer `Map<K, V>` or dedicated classes with explicit `.get()` and `.has()` methods.
- **Deprecation / Breaking Change Process**: If changing a public object's prototype to `null` is unavoidable, it must follow Angular's formal deprecation and major version breaking change process.
---
## 3. When `Object.create(null)` Should NOT Be Used
Do not replace `{}` with `Object.create(null)` in the following scenarios:
1.**Fixed-Shape Structs and DTOs:** Objects with hardcoded static property names (e.g., `let sortedBreakpoints: {breakpoints?: number[]} = {}`). `Object.assign({}, ...)` only copies _own_ enumerable properties, so prototype properties on sources are never copied.
2.**Numeric-Key Maps:** Objects indexed by numbers (e.g., `tasksByHandleId: {[id: number]: Task}`). Numeric keys do not collide with `Object.prototype` string members.
3.**Reference Sentinels:** Objects used purely for reference identity checks (e.g., `const EMPTY_OBJECT = {}` or `const IN_PROGRESS_RESOLUTION = {}`).
4.**Internal Compiler AST and Visitor State:** Temporary objects with internally generated keys where untrusted user input cannot poison key names.
5.**Hot Performance Paths and Size-Critical Bundles:** Standard `{}` literals use V8 fast hidden classes and monomorphic inline caching. `Object.create(null)` forces V8 dictionary mode and increases minified bundle size (e.g., in inline polyfills like `event-dispatch-contract` or SSR hydration bundles).
When reviewing pull requests that modify the Angular Router (`packages/router`), pay special attention to the following:
- **Timing Sensitivity**: The router is extremely sensitive to timing changes. Any changes that alter the asynchronous timing of navigations, resolvers, or guards are almost always breaking changes and must be scrutinized carefully.
- **Testing Practices**: Tests should usually use the `RouterTestingHarness`. Many existing tests are older and do not use this harness. Do not blindly follow the shape of existing tests when writing or reviewing new ones; encourage the use of modern testing utilities.
- **Feature Justification**: Changes to router core code should be well-justified. Consider whether the change is proven to be a core developer ask, such as resolving a highly upvoted GitHub issue or addressing a critical bug.
description: Explains the mental model and architecture of the code under `packages/compiler-cli`. You MUST use this skill any time you plan to work with code in `packages/compiler-cli`
---
# Angular Compiler CLI (`ngtsc`) Architecture
## Overview
The `packages/compiler-cli` package contains the Angular Compiler (Ivy), often referred to as `ngtsc`. It is a wrapper around the TypeScript compiler (`tsc`) that extends it with Angular-specific capabilities.
The core goal of `ngtsc` is to compile Angular decorators (like `@Component`, `@Directive`, `@Pipe`) into static properties on the class (Ivy instructions, e.g., `static ɵcmp = ...`). It also performs template type checking and ahead-of-time (AOT) compilation.
## Mental Model
The compiler is designed as a **lazy, incremental, and partial** compilation pipeline.
1.**Wrapper Pattern**: `NgtscProgram` wraps the standard `ts.Program`. It intercepts calls to act as a drop-in replacement for standard tooling.
2.**Traits System**: Every class with an Angular decorator is considered a "Trait". The compiler manages the state of these traits through a state machine:
- **Resolved**: Dependencies (directives/pipes in template) resolved, import cycles handled.
- **Skipped**: Not an Angular class.
3.**Lazy Analysis**: Analysis only happens when necessary (e.g., when diagnostics are requested or emit is prepared).
4.**Output AST**: The compiler generates an intermediate "Output AST" (`o.Expression`) for the generated code, which is then translated into TypeScript AST nodes during the emit phase.
## Key Subsystems
### 1. Core Orchestration (`ngtsc/core`)
- **`NgtscProgram`**: The public API implementing `api.Program`. It manages the `ts.Program` and the `NgCompiler`.
- **`NgCompiler`**: The brain of the compiler. It orchestrates the compilation phases (Analysis, Resolution, Type Checking, Emit). It holds the `TraitCompiler`.
### 2. Trait Compilation (`ngtsc/transform`)
- **`TraitCompiler`**: Manages the lifecycle of "Traits". It iterates over source files, identifies decorated classes, and delegates to the appropriate `DecoratorHandler`.
- **`Trait`**: A state container for a class, holding its handler, analysis results, and resolution results.
### 3. Decorator Handlers (`ngtsc/annotations`)
- **`DecoratorHandler`**: An interface for handling specific decorators.
- **`ComponentDecoratorHandler`**: The most complex handler. It:
- Extracts metadata (selector, inputs, outputs).
- Parses the template.
- Resolves used directives and pipes (`R3TargetBinder`).
- Generates the `ɵcmp` instruction.
- **`DirectiveDecoratorHandler`**, **`PipeDecoratorHandler`**, **`NgModuleDecoratorHandler`**: Handle their respective decorators.
### 4. Template Type Checking (`ngtsc/typecheck`)
- **`TemplateTypeChecker`**: Generates "Type Check Blocks" (TCBs). A TCB is a block of TypeScript code that represents the template's logic in a way `tsc` can understand and check for errors.
- **`TypeCheckBlock`**: The actual generated code that validates bindings, events, and structural directives.
- **`MetadataReader`**: Reads Angular metadata from source files (using `LocalMetadataRegistry`) and `.d.ts` files (using `DtsMetadataReader`).
- **`ScopeRegistry`**: Determines the "compilation scope" of a component (which directives/pipes are available to it), handling `NgModule` transitive exports and Standalone Component imports.
### 6. Emit & Transformation (`ngtsc/transform`)
- **`ivyTransformFactory`**: A TypeScript transformer factory.
- **`IvyCompilationVisitor`**: Visits classes, triggers compilation via `TraitCompiler`, and collects the Output AST.
- **`IvyTransformationVisitor`**: Translates the Output AST into TypeScript AST, injects the `static ɵ...` fields, and removes the original decorators.
## Compilation Phases
1.**Construction**: `NgtscProgram` creates `NgCompiler`, which sets up all registries and the `TraitCompiler`.
2.**Analysis** (`analyzeSync`):
- The `TraitCompiler` scans files.
-`DecoratorHandler`s extract metadata and parse templates.
- No cross-file resolution happens here (allowing for parallelism and caching).
3.**Resolution** (`resolve`):
-`TraitCompiler` resolves traits.
- Components link their templates to specific Directives and Pipes (found via `ScopeRegistry`).
- Import cycles are detected and handled (e.g., via "remote scoping").
4.**Type Checking**:
-`TemplateTypeChecker` creates TCBs for all components.
- TypeScript diagnostics are retrieved for these TCBs.
5.**Emit** (`prepareEmit`):
-`ivyTransformFactory` is created.
- TS `emit` is called.
- The transformers run, injecting the compiled Ivy instructions into the JS/DTS output.
## Important File Locations
-`packages/compiler-cli/src/ngtsc/program.ts`: Entry point (`NgtscProgram`).
description: Explains the mental model and architecture of the code under `packages/core`. You MUST use this skill any time you plan to work with code in `packages/core`
---
# Angular Core (`packages/core`) Mental Model
This document outlines the architecture and mental model for `packages/core`, the heart of the Angular framework.
## 1. High-Level Architecture
`packages/core` contains the runtime logic for Angular. Its primary responsibilities are:
1.**Rendering (Ivy/Render3)**: Transforming templates into DOM updates.
2.**Dependency Injection (DI)**: Managing object creation and lifetime.
3.**Change Detection**: Synchronizing the model with the view.
4.**Reactivity**: Signals and Zone.js integration.
## 2. Rendering Engine (Ivy / Render3)
The rendering engine (located in `packages/core/src/render3`) uses an **instruction-based** approach.
### Key Concepts
- **Instructions**: The Angular compiler transforms templates into a sequence of instruction calls (e.g., `ɵɵelementStart`, `ɵɵtext`, `ɵɵproperty`). These instructions are executed at runtime to create and update the view.
- **TView (Template View)**: An array containing the _static structure_ of a view. It is shared across all instances (`LView`s) of the same component/template. It holds:
- Configured via `@Component.providers` or `@Directive.providers`.
- **Not a class**, but a data structure embedded in the `LView` ("Expando" section).
- Uses **Bloom Filters** (`TView.data`) to quickly check if a token is present at a specific node index before traversing up the tree.
- Resolves tokens starting from the current node, walking up the view tree (Element Injector hierarchy), and falling back to the Module Injector if not found.
## 4. Change Detection
- **Dirty Checking**: Angular checks if values bound in templates have changed.
- **Strategies**:
-`Default`: Checks everything.
-`OnPush`: Checks only if inputs change, events fire, or signals update.
- **Signals**: The new reactivity primitive. Signals notify the scheduler when they change, potentially allowing for fine-grained updates (Zoneless).
## 5. Key Directories to Know
-`src/render3`: The Ivy rendering engine.
-`instructions`: The runtime instructions called by compiled code.
-`src/signal`: Signals implementation (if present in this version, otherwise likely in `primitives`).
## 6. Conventions & Gotchas
- **Prefixes**: Private/Internal exports often start with `ɵ`.
- **Global State**: Ivy relies heavily on global state (e.g., `getLView()`) during instruction execution to avoid passing context arguments everywhere. This is for performance and code size.
- **Performance**: The code is highly optimized for performance and memory. You will see arrays used instead of objects, bitmasks, and manual memory management patterns. **Respect these patterns.**
## 7. How to Modify Core
1.**Understand the Instruction**: If modifying runtime behavior, find the corresponding instruction in `src/render3/instructions`.
2.**Check `LView`/`TView` Impact**: If adding state, understand where it fits in the `LView` array.
3.**Tests**: Core has extensive tests. Run them using Bazel.
description: Explains the mental model and architecture of the code under `packages/forms/signals`. You MUST use this skill any time you plan to work with code in `packages/forms/signals`
---
# Signal Forms Architecture
The `packages/forms/signals` directory contains the signal-based forms API for Angular.
This system differs significantly from the existing Reactive and Template-driven forms.
## Mental Model
1.**Model-Driven**: The system is built around a `WritableSignal<T>` which serves as the **single source of truth**.
Unlike Reactive Forms where the `FormControl` holds the value, here the `Signal` holds the value.
The form is merely a _view_ or _projection_ of that signal, adding form-specific state (validity, dirty, touched).
2.**Proxy-Based Traversal**: The form API (`form(signal)`) returns a `FieldTree`. This object is a **Proxy**.
It allows accessing nested fields (e.g., `myForm.user.name`) without manually creating control groups.
Accessing a property on the proxy lazily resolves or creates the corresponding `FieldNode`.
3.**Schema-Based Logic**: Validation, disabled state, and other metadata are defined separately via **Schemas**.
Schemas are applied to the form structure using functions like `apply`, `applyEach` (for arrays), and `applyWhen`.
This separates the _structure_ of the data from the _rules_ governing it.
4.**Directives as Glue**: The `[formField]` directive binds a DOM element (native input or custom control) to a `FieldNode`.
It handles:
- Syncing the value between the DOM and the Signal.
- Reflecting state (valid, touched, etc.) to the UI.
- Handling user interaction events (blur, input).
## Key Components
### 1. `FieldNode` (`src/field/node.ts`)
The central internal class representing a single field in the form graph. It aggregates several state managers:
-`structure`: Manages parent/child relationships and signal slicing.
This document explains how the Signal Forms system hooks into the Angular compiler and runtime to provide seamless type-checking and efficient updates.
## 1. Compiler Integration (Type Checking)
The `packages/compiler` package contains specific logic to support `[formField]`. This is primarily handled in `src/typecheck/ops/signal_forms.ts`.
### Key Mechanisms:
- **Detection**: The compiler identifies a directive as a "Field Directive" if it has the `ɵNgFieldDirective` property or comes from `@angular/forms/signals`.
- **Synthetic Binding Expansion**: When you write `<input [formField]="mySignal" />`, the type checker doesn't just check `formField`. It synthetically expands this into a set of bindings for validation:
-`[value]="mySignal()"` (or `checked` for checkboxes)
-`[disabled]="mySignal.disabled()"`
-`[required]="mySignal.required()"`
- ...and so on.
- This ensures that `mySignal` (the `FieldNode`) has all the necessary properties to drive the form control.
- **Conflict Detection**: It actively prevents "double binding". If you bind `[formField]`, you are _banned_ from also binding `[value]`, `[disabled]`, `[required]`, etc., as the signal form should be the single source of truth.
- **Element Type Validation**:
- **Native Elements**: Checks that the signal's value type matches the element type (e.g., `<input type="checkbox">` requires a `boolean` signal).
- **Custom Controls**: Detects if a custom component is a "Form Value Control" (has a `value` input/output) or "Form Checkbox Control" (has a `checked` input/output) and validates against that.
### Relevant Files:
-`packages/compiler/src/typecheck/ops/signal_forms.ts`: The core Signal Forms type-checking logic, including `TcbNativeFieldOp`.
## 2. Core Runtime Integration
The `packages/core` package provides the low-level instructions that power the `FormField` directive. This allows it to do things normal directives cannot, like efficiently syncing state without change detection overhead for every property.
### Key Mechanisms:
- **`ɵngControlCreate` Hook**: The `FormField` directive defines a special method `ɵngControlCreate`, which causes the compiler to install `ɵɵControlFeature`.
- **`ɵɵcontrol` Instructions**: A `formField` binding causes the compiler to emit:
-`ɵɵcontrolCreate`: Called during the creation phase.
-`ɵɵcontrol`: Called during the update phase.
- **`ControlDirectiveHost`**: These instructions provide the directive with a `ControlDirectiveHost`. This is a privileged interface that allows the `FormField` directive to:
- **Access the Element**: Get direct access to the native element or component instance.
- **Set Inputs**: Write directly to inputs of _other directives_ on the same node (e.g., setting the `value` input of a custom control).
- **Listen to Outputs**: Subscribe to outputs of other directives (e.g., `valueChange`).
- **Bypass Templates**: It effectively acts as a "meta-directive" that manages the bindings for you, bypassing the need for explicit template syntax for every property.
### Relevant Files:
-`packages/core/src/render3/instructions/control.ts`: Implementation of `ɵɵcontrol` instructions.
-`packages/forms/signals/src/directive/form_field.ts`: The directive that implements the hook.
# **NOTE 1**: Pin to exact images using an ID (SHA). See https://circleci.com/docs/2.0/circleci-images/#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version.
# (Using the tag in not necessary when pinning by ID, but include it anyway for documentation purposes.)
# **NOTE 2**: If you change the version of the docker images, also change the `cache_key` suffix.
# **NOTE 3**: If you change the version of Node.js provided by the docker images, also update `.devcontainer/recommended-Dockerfile` to match the new version.
This folder contains configuration files that can be used to opt into working on this repository in a [Docker container](https://www.docker.com/resources/what-container) via [VSCode](https://code.visualstudio.com/)'s Remote Development feature (see below).
Info on remote development and developing inside a container with VSCode:
- [VSCode: Developing inside a Container](https://code.visualstudio.com/docs/remote/containers)
- [VSCode: Remote Development FAQ](https://code.visualstudio.com/docs/remote/faq)
## Usage
_Prerequisite: [Install Docker](https://docs.docker.com/install) on your local environment._
To get started, read and follow the instructions in [Developing inside a Container](https://code.visualstudio.com/docs/remote/containers). The [.devcontainer/](.) directory contains pre-configured `devcontainer.json` and `Dockerfile` files, which you can use to set up remote development with a docker container.
To get started, read and follow the instuctions in [Developing inside a Container](https://code.visualstudio.com/docs/remote/containers). The [.devcontainer/](.) directory contains pre-configured `devcontainer.json` and `Dockerfile` files, which you can use to set up remote development with a docker container.
In a nutshell, you need to:
- Install the [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension.
- Copy [recommended-Dockerfile](./recommended-Dockerfile) to `Dockerfile` (and optionally tweak to suit your needs).
- Copy [recommended-devcontainer.json](./recommended-devcontainer.json) to `devcontainer.json` (and optionally tweak to suit your needs).
@@ -24,6 +23,7 @@ In a nutshell, you need to:
The `.devcontainer/devcontainer.json` and `.devcontainer/Dockerfile` files are ignored by git, so you can have your own local versions. We may occasionally update the template files ([recommended-devcontainer.json](./recommended-devcontainer.json), [recommended-Dockerfile](./recommended-Dockerfile)), in which case you will need to manually update your local copies (if desired).
## Updating `recommended-devcontainer.json` and `recommended-Dockerfile`
You can update and commit the recommended config files (which people use as basis for their local configs), if you find that something is broken, out-of-date or can be improved.
description="Researches part of the codebase and creates a skill for it"
prompt="""
## Role
You are an experienced senior developer specializing in reverse engineering and understanding
complex code, prompt engineering, and context engineering.
Your task is to build a complete understanding of the mental model and architecture of the code,
and to create an efficient context file that allows a coding agent to understand and work with the
code.
## Guiding Principles
1. **Deep Analysis:** Understand the _why_ behind the code. Not just a surface level listing of
files and classes.
2. **Curiosity:** Be curious. If something is unclear, confusing, or unexpected you _MUST_
investigate further until you fully understand.
3. **Efficient Token Use:** The final output will be directly included into the context of the
coding assistant, so be sure to make efficient use of tokens. Think deeply, but only capture the
most important information for the coding agent in the final output
## Procedure
1. Fully explore the code before first, with a focus on understanding the architecture and how all
of the pieces fit together.
2. Develop an understanding of the mental model behind the architecture. _Why_ is the code is
architected this way? How should developers think about the system?
3. Document your findings using the given output format described in the next section.
## Output Format
Note the following placeholders below:
- `[package]`: is a unique identifier for the current code package (for example if you're looking at
code under `packages/forms/signals` you might use `signal-forms` as the `[package]`)
- `[code-location]`: is the location of the current code within the larger repository
- `[context]`: is the context to add to the coding agent when it is working with this code.
With those placeholders in mind, write a file create a new directory under `.gemini/skills` with the
name `reference-[package]/`, and under that directory add a `SKILL.md` file with the following
content:
```md
---
name: reference-[package]
description: Explains the mental model and architecture of the code under `[code-location]`. You MUST use this skill any time you plan to work with code in `[code-location]`
---
[context]
```
## Additional User Instructions
The user may have additional instructions.
- The user should indicate what package to research
- The user may indicate that they want to update a package that has already been researched. In this
case, read the existing skill and make any required updates based on your research
- The user may request supplemental information be added to the skill (if so, add this to the
existing skill in a new markdown file under a `references` directory within the skill. Add a
section to the main `SKILL.md` that mentions what supplemental information is available)
# the g3 status will be added to your pull requests if they include files that match the patterns
g3Status:
# set to true to disable
disabled:true
disabled:false
# the name of the status
context:'google3'
# text to show when the status is pending, {{PRNumber}} will be replaced by the PR number
@@ -32,8 +32,51 @@ merge:
# link to use for the details
url:'http://go/angular/g3sync'
# list of patterns to check for the files changed by the PR
# this list must be manually kept in sync with google3/third_party/javascript/angular2/copy.bara.sky
include:
- 'LICENSE'
- 'modules/benchmarks/**'
- 'modules/system.d.ts'
- 'packages/**'
# list of patterns to ignore for the files changed by the PR
exclude:
- 'packages/*'
- 'packages/bazel/*'
- 'packages/bazel/src/api-extractor/**'
- 'packages/bazel/src/builders/**'
- 'packages/bazel/src/ng_package/**'
- 'packages/bazel/src/protractor/**'
- 'packages/bazel/src/schematics/**'
- 'packages/compiler-cli/src/ngcc/**'
- 'packages/compiler-cli/linker/**'
- 'packages/compiler-cli/ngcc/**'
- 'packages/compiler-cli/src/ngtsc/sourcemaps/**'
- 'packages/docs/**'
- 'packages/elements/schematics/**'
- 'packages/examples/**'
- 'packages/language-service/**'
- 'packages/localize/**'
- 'packages/private/**'
- 'packages/service-worker/**'
- 'packages/common/locales/**'
- 'packages/http/**'
- '**/.gitignore'
- '**/.gitkeep'
- '**/yarn.lock'
- '**/package.json'
- '**/third_party/**'
- '**/tsconfig-build.json'
- '**/tsconfig.json'
- '**/rollup.config.js'
- '**/BUILD.bazel'
- '**/*.md'
- 'packages/**/integrationtest/**'
- 'packages/**/test/**'
- 'packages/zone.js/*'
- 'packages/zone.js/dist/**'
- 'packages/zone.js/doc/**'
- 'packages/zone.js/example/**'
- 'packages/zone.js/scripts/**'
# comment that will be added to a PR when there is a conflict, leave empty or set to false to disable
mergeConflictComment:"Hi @{{PRAuthor}}! This PR has merge conflicts due to recent upstream merges.\nPlease help to unblock it by resolving these conflicts. Thanks!"
@@ -55,9 +98,10 @@ merge:
# whether the PR shouldn't have a conflict with the base branch
noConflict:true
# list of labels that a PR needs to have, checked with a regexp.
# list of labels that a PR needs to have, checked with a regexp (e.g. "target:" will work for the label "target: master")
requiredLabels:
- 'target:*'
- 'cla:yes'
# list of labels that a PR shouldn't have, checked after the required labels with a regexp
forbiddenLabels:
@@ -65,16 +109,21 @@ merge:
- 'action:cleanup'
- 'action:review'
- 'state:blocked'
- 'cla:no'
# list of PR statuses that need to be successful
requiredStatuses:
- 'google-internal-tests'
- 'ci/circleci:build'
- 'ci/circleci:lint'
- 'ci/angular:size'
- 'cla/google'
- 'google3'
- 'pullapprove'
# the comment that will be added when the merge label is added despite failing checks, leave empty or set to false to disable
# {{MERGE_LABEL}} will be replaced by the value of the mergeLabel option
# {{PLACEHOLDER}} will be replaced by the list of failing checks
mergeRemovedComment:"I see that you just added the `{{MERGE_LABEL}}` label, but the following checks are still failing:\n{{PLACEHOLDER}}\n\n**If you want your PR to be merged, it has to pass all the CI checks.**\n\nIf you can't get the PR to a green state due to flakes or broken `main`, please try rebasing to `main` and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help."
mergeRemovedComment:"I see that you just added the `{{MERGE_LABEL}}` label, but the following checks are still failing:\n{{PLACEHOLDER}}\n\n**If you want your PR to be merged, it has to pass all the CI checks.**\n\nIf you can't get the PR to a green state due to flakes or broken master, please try rebasing to master and/or restarting the CI job. If that fails and you believe that the issue is not due to your change, please contact the caretaker and ask for help."
# options for the triage plugin
triage:
@@ -84,29 +133,29 @@ triage:
defaultMilestone:82,
# arrays of labels that determine if an issue has been triaged by the caretaker
l1TriageLabels:
- - 'area:*'
- - 'comp:*'
# arrays of labels that determine if an issue has been fully triaged
l2TriageLabels:
- - 'P0'
- 'area:*'
- 'comp:*'
- - 'P1'
- 'area:*'
- 'comp:*'
- - 'P2'
- 'area:*'
- 'comp:*'
- - 'P3'
- 'area:*'
- 'comp:*'
- - 'P4'
- 'area:*'
- 'comp:*'
- - 'P5'
- 'area:*'
- 'comp:*'
- - 'feature'
- 'area:*'
- 'comp:*'
- - 'discussion'
- 'area:*'
- 'comp:*'
- - 'needs clarification'
- 'area:*'
- 'comp:*'
- - 'needs reproduction'
- 'area:*'
- 'comp:*'
# options for the triage PR plugin
triagePR:
@@ -118,10 +167,10 @@ triagePR:
defaultMilestone:82,
# arrays of labels that determine if a PR has been triaged by the caretaker
l1TriageLabels:
- - 'area:*'
- - 'comp:*'
# arrays of labels that determine if a PR has been fully triaged
'@angular/animations is deprecated. Use `animate.enter` and `animate.leave` instead. For more information see: https://v22.angular.dev/guide/animations.',
},
},
{name:'@angular/common'},
{name:'@angular/compiler-cli'},
{name:'@angular/compiler'},
{name:'@angular/core'},
{name:'@angular/elements'},
{name:'@angular/forms'},
{name:'@angular/language-server'},
{name:'@angular/language-service'},
{name:'@angular/localize'},
{
name:'@angular/platform-browser-dynamic',
deprecated:{
version:'>=20.1.0-next.0',
message:
'@angular/platform-browser-dynamic is deprecated. Use `@angular/platform-browser` instead.',
},
},
{name:'@angular/platform-browser'},
{name:'@angular/platform-server'},
{name:'@angular/router'},
{name:'@angular/service-worker'},
{name:'@angular/upgrade'},
],
buildPackages:async()=>{
// The buildTargetPackages function is loaded at runtime as the loading the script
File diff suppressed because it is too large
Load Diff
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.