`Object.values` is not supported in IE11 without a polyfill. The quickest,
most straightfoward fix for this is to simply use `Object.keys` instead.
We may want to consider including the polyfill in the CLI in the future
or just wait until IE11 support is dropped before using
`Object.values`.
PR Close#40370
This commit documents how to add a helper function which combines all the params
in the router state tree into a single object. It provides a starting point for
developers to reference if they require a more fine-tuned approach.
Fixes#11023
PR Close#40306
When we attach a `ViewRef` to a `ViewContainerRef`, we save a reference to the container
onto the `ViewRef` so that we can remove it when the ref is destroyed. The problem is
that if the container's `hostView` is destroyed first, the `ViewRef` has no way of knowing
that it should stop referencing the container.
These changes remove the leak by not saving a reference at all. Instead, when a `ViewRef`
is destroyed, we clean it up through the `LContainer` directly. We don't need to worry
about the case where the container is destroyed before the view, because containers
automatically clean up all of their views upon destruction.
Fixes#38648.
PR Close#40219
The `NgControlStatusGroup` directive is shared between template-driven and reactive form modules. In cases when
only reactive forms module is present, the `NgControlStatusGroup` directive is still activated on all `<form>`
elements, but if there is no other reactive directive applied (such as `formGroup`), corresponding `ControlContainer`
token is missing, thus causing exceptions (since `NgControlStatusGroup` directive relies on it to determine the
status). This commit updates the logic to handle the case when no `ControlContainer` is present (effectively making
directive logic a noop in this case).
Alternative approach (more risky) worth considering in the future is to split the `NgControlStatusGroup` into
2 directives with different set of selectors and include them into template-driven and reactive modules separately.
The downside is that these directives might be activated simultaneously on the same element (e.g. `<form>`),
effectively doing the work twice.
Resolves#38391.
PR Close#40344
Delaying the check if a closed PR was closed by a merge or just closed by 30 seconds
allows for Github to have time to update the PR to be associated to the commit which
closed the PR. Without this delay, a race condition can exist in which we check for
how a PR was closed before this association is made.
PR Close#40181
`Object.entries` is not supported in IE11 without a polyfill. The quickest,
most straightfoward fix for this is to simply use `Object.keys` instead.
We may want to consider including the polyfill in the CLI in the future
or just wait until IE11 support is dropped before using
`Object.entries`.
PR Close#40340
PR #34934 switched the `getting-started` docs example from using the
index of a product in the `products` array to using the product's ID
property for indentifiying each product in the `ProductDetailsComponent`
component. However, some necessary changes in the example code and the
`start-routing.md` guide were missed in #34934, resulting in broken
instructions for the readers (see #40189).
This commit is essentially a follow-up to #34934, making the remaining
changes in the example code and the guide instructions.
Fixes#40189
PR Close#40197
This commit slightly refactors the code in the `get-product` docregion
of the `getting-started` docs example to make it easier to follow.
PR Close#40197
This commit does some minor clean-up in docregions of the
`getting-started` docs example. More specifically, it:
- Removes redundant docregion markers.
- Fixes whitespace inconsistencies.
- Adds `/* ... */` to indicate that there is more code before the end of
a docregion (in order to avoid confusion).
PR Close#40197
This commit aligns the code and style in the `getting-started-v0` docs
example with that of the `getting-started` example more closely (except
for the the parts that are intentionally different between the two).
PR Close#40197
During route activation, a componentless route will not have a context created
for it, but the logic continues to recurse so that children are still
activated. This can be seen here:
https://github.com/angular/angular/blob/362f45c4bf1bb49a90b014d2053f4c4474d132c0/packages/router/src/operators/activate_routes.ts#L151-L158
The current deactivation logic does not currently account for componentless routes.
This commit adjusts the deactivation logic so that if a context cannot
be retrieved for a given route (because it is componentless), we
continue to recurse and deactivate the children using the same
`parentContexts` in the same way that activation does.
Fixes#20694
PR Close#40196
CSS supports escaping in selectors, e.g. writing `.foo:bar` will match an element with the
`foo` class and `bar` pseudo-class, but `.foo\:bar` will match the `foo:bar` class. Our
shimmed shadow DOM encapsulation always assumes that `:` means a pseudo selector
which breaks a selector like `.foo\:bar`.
These changes add some extra logic so that escaped characters in selectors are preserved.
Fixes#31844.
PR Close#40264
In some browsers, notably a mobile version of webkit on iPad, the
result of calling `DOMParser.parseFromString()` returns a document
whose `body` property is null until the next tick of the browser.
Since this is of no use to us for sanitization, we now fall back to the
"inert document" strategy for this case.
Fixes#39834
PR Close#40107
The `yarn symbol-extractor:check` and `yarn symbol-extractor:update` commands don't seem to work currently -
the script is unable to calculate the list of relevant targets. Running the `bazel query ...` command used in the
script fails due to the missing quotes around the query argument. This commit fixes the problem by updating the
script to wrap query argument into single quotes.
PR Close#40163
The link to the "speeding-up-ngcc-compilation" URL does not exist,
it was removed shortly after it was added, but the link in the ngcc
error message was not updated.
Fixes#39837
PR Close#40285
https://developer.mozilla.org/en-US/docs/Web/CSS/font-family
"You should always include at least one generic family name in a font-family list,
since there's no guarantee that any given font is available. This lets the browser
select an acceptable fallback font when necessary."
PR Close#40254
Currently we check whether a property binding contains an interpolation using a regex so
that we can throw an error. The problem is that the regex doesn't account for quotes
which means that something like `[prop]="'{{ foo }}'"` will be considered an error, even
though it's not actually an interpolation.
These changes build on top of the logic from #39826 to account for interpolation
characters inside quotes.
Fixes#39601.
PR Close#40267
When talking about parameter inheritance, one might think that matrix
parameters can be inherited from the "parent" segment, or the segment
which appears immediately to the left. In reality, when we talk about
a "parent" in the `Router`, we mean the parent `Route` config. This
config may contain more than one segment and matrix parameters must
appear at the end or they do not "belong" to any config.
PR Close#40304
There are two parts to this commit:
1. Revert the changes from #38379. This change had an incomplete view of
how things worked and also diverged the implementations of
`applyRedirects` and `recognize` even more.
2. Apply the fixes from the `recognize` algorithm to ensure that named
outlets with empty path parents can be matched. This change also passes
all the tests that were added in #38379 with the added benefit of being
a more complete fix that stays in-line with the `recognize` algorithm.
This was made possible by using the same approach for `split` by
always creating segments for empty path matches (previously, this was
only done in `applyRedirects` if there was a `redirectTo` value). At the
end of the expansions, we need to squash all empty segments so that
serializing the final `UrlTree` returns the same result as before.
Fixes#39952Fixes#10726Closes#30410
PR Close#40029
PR Close#40315
The `applyRedirects` and `recognize` algorithms have the same overall goal:
match a `UrlTree` with the application's `Routes` config. There are a
few key functions in these algorithms which can be shared rather than
duplicated between the two. This also makes it easier to see how the two
are similar and where they diverge.
PR Close#40029
PR Close#40315
This commit updates the `recognize` algorithm to work with named outlets
which have empty path parents. For example, given the following config
```
const routes = [
{
path: '',
children: [
{path: 'a', outlet: 'aux', component: AuxComponent}
]}
];
```
The url `/(aux:a)` should match this config. In order to do so, we need
to allow the children of `UrlSegmentGroup`s to match a `Route` config
for a different outlet (in this example, the `primary`) when it's an
empty path. This should also *only* happen if we were unable to find a
match for the outlet in the level above. That is, the matching strategy
is to find the first `Route` in the list which _matches the given
outlet_. If we are unable to do that, then we allow empty paths from
other outlets to match and try to find some child there whose outlet
matches our segment.
PR Close#40029
PR Close#40315
To make the tests suite easier to follow, `Recognize#apply` can be made
into a synchronous function rather than one that return an `Observable`.
Also, as a chore, remove as many `any` types as possible.
PR Close#40029
PR Close#40315
This commit updates the `recognize` algorithm to return `null` when a
segment does not match a given config rather than throwing an error.
This makes the code much easier to follow because the "no match" result
has to be explicitly handled rather than catching the error in very
specific places.
PR Close#40029
PR Close#40315
When stepping through the `recognize` algorithm, it is much easier to
follow when using a simple `for...of` rather than the helper
`mapChildrenIntoArray` with the passed closure. The only special thing that
`mapChildrenIntoArray` does is ensure the primary route appears first.
This change will have no affect on the result because `processChildren` later calls
`sortActivatedRouteSnapshots`, which does the same thing.
PR Close#40029
PR Close#40315
DI providers can be defined via `useFactory` function, which may have arguments configured via `deps` array.
The `deps` array may contain DI flags represented by DI decorators (such as `@Self`, `@SkipSelf`, etc). Prior to this
commit, having the `@Host` decorator in `deps` array resulted in runtime error in Ivy. The problem was that the `@Host`
decorator was not taken into account while `useFactory` argument list was constructed, the `@Host` decorator was
treated as a token that should be looked up.
This commit updates the logic which prepares `useFactory` arguments to recognize the `@Host` decorator.
PR Close#40122
PR Close#40313
According to the [spec](https://html.spec.whatwg.org/#scroll-to-fragid),
we should attempt to set the browser focus after scrolling to a
fragment. Note that this change does not exactly follow the robust steps
outlined in the spec by finding a fallback target if the original is not
focusable. Instead, we simply attempt to focus the element by calling
`focus` on it, which will do nothing if the element is not focusable.
fixes#30067
PR Close#40241
With this change we change the `Boolean and enumerated options` to use kebab-case flags
as the camelCase variant are deprecated. We also remove the `enumerated option description`
as this is no longer correct and needed following the CLI MAN page update in #40038
PR Close#40224
Internally we store lifecycle hooks in the format `[index, hook, index, hook]` and when
iterating over them, we check one place ahead to figure out whether we've hit found
a hook or an index. The problem is that the loop is set up to iterate up to `hooks.length`
which means that we may go out of bounds on the last iteration, depending on where
we started. This appears to happen under a specific set of circumstances where a
directive calls `detectChanges` from an input setter while it has `ngOnChanges` and
`ngAfterViewInit` hooks.
These changes resolve the issue by only iterating up to `length - 1` which guarantees that
we can always look one place ahead.
This appears to have regressed some time in version 10.
Fixes#38611.
PR Close#40206
Previously `\r\n` was being treated as a single character in source-map
line start positions, which caused segment positions to become offset.
Now the `\r` is ignored when splitting, leaving it at the end of the
previous line, which solves the offsetting problem, and does not affect
source-mappings.
Fixes#40169Fixes#39654
PR Close#40187
PR #39876 introduced an error where the `onDestroy` of `ComponentRef`
would only get called if `ngDevMode` was set to true. This was because
in dev mode we would freeze `TCleanup` to verify that no more
static cleanup would get added to `TCleanup` array. This ensured
that `TCleanup` was always present in dev mode. In production the
`TCleanup` would get created only when needed. The resulting cleanup
code was incorrectly indented and would only run if `TCleanup` was
present causing this issue.
Fix#40105
PR Close#40120
Previously, the `SpyDirective` in the `lifecycle-hooks` docs example
would use a different ID when logging `onInit` and when logging
`onDestroy` for the same instance, making it impossible to associate the
two calls. This was not helpful and came in constrast with how the
directive was described in the corresponding guide and shown in the
accompanying `spy-directive.gif` image.
This commit fixes the logic of the `SpyDirective` class to use the same
ID for all log operations of an instance.
Partially addresses #40193.
PR Close#40208
Previously, the docregion code referenced a `nextId` variable that was
not shown in the code, which was confusing for the reader.
This commit makes the declaration of the `nextId` variable part of the
docregion, so it is clear to the reader where it comes from and how it
is initialized.
This commit also removes the `logIt()` helper method, which didn't seem
to add value and calls `logger.log()` directly instead.
PR Close#40208
This commit aligns the order of the links to the various sections of the
`lifecycle-hooks` docs example with the order in which the sections
appear in the template (which also coincides with the order in which
they are presented/discussed in the corresponding guide).
PR Close#40208
This commit updates the versions of Chrome and Firefox used in tests -
both with Bazel and without (via Puppeteer) - to the latest:
- Chrome v87
- Firefox v84
PR Close#40150
This commit adds instructions in `dev-infra/browsers/README.md` on how
to update the version of GeckoDriver (the WebDriver implementation for
Firefox browsers).
NOTE:
The gecko driver download URLs perform redirection, so the `curl`
command needs to be run with the `-L/--location` option to follow
redirects. I updated all `curl` commands (even those that are not used
on gecko driver download URLs) for consistency.
PR Close#40150
Previously, the instructions and process for updating the version of
Chrome ued in tests assumed that there was always going to be a
ChromeDriver version that corresponded to a Chrome version. For example,
if we wanted to use Chrome v87.0.4272.x, we assumed that there was going
to be ChromeDriver v87.0.4272.x. It turns out that this is not always
the case.
This commit updates the instructions and process for updating the Chrome
version to ensure a valid version of ChromeDriver will be used as well.
PR Close#40150
This commit fixes the instructions in `dev-infra/browsers/README.md` to
use the `shasum` executable (instead of `sha256`, which does not exist
afaict).
The commit also fixes a couple of typos.
PR Close#40150
This commit refactor the `dev-infra/browsers/README.md` file to have one
sentence per line. This makes it consistent with other Markdown files in
the repository and makes diffs for future changes more readable.
This commit also uses proper Markdown numbered lists and fixes
indentation.
PR Close#40150
This commit updates `lighthouse` to version 7.0.0.
It also adds a `width` attribute to the `code-icon.svg` image on the
homepage, which was pointed out as missing in the Lighthouse report.
(Explicit `width`/`height` attributes on images help reduce the
[layout shift][1] of the page.)
[1]: https://web.dev/cls/
PR Close#40198
Angular has stopped to support browser that requires that CSS property.
All supported browsers support standard transition-timing-function CSS property
PR Close#40153
Previously, due to a bug in `rebase-pr.js`, PRs for branches containing
a slash (/) in their name would fail to be rebased
([example failure][1]).
This commit ensures that such branch names are handled correctly.
[1]: https://circleci.com/gh/angular/angular/884503
PR Close#40184
This commit adds the "outFiles" config options into the .vscode/recommended-launch.json, which helps speed up
the startup time of a debugging session by limiting the number of files that should be loaded.
PR Close#39848
As part of the `setup` CI job (which is a prerequisite for all other CI
jobs), we rebase the current code on master to make sure the PR changes
are compatible with the latest code from master, even if the PR has not
been rebased recently.
When it is not possible to automatically rebase (i.e. when there are
conflicts that need to be resolved manually), the job and subsequently
the entire workflow should fail.
This behavior has been accidentally broken in #39592, so that the job
would succeed even if the rebase operation failed.
This commit fixes it by ensuring the `exec()` helper used in
`rebase-pr.js` will throw an error if the underlying command execution
fails. Previously, the function would always return stdout output as a
string and attach a `code` property indicating the exit code of the
command.
Since the exit code isn't necessary in the `rebase-pr.js` script, this
commit simplifies the `exec()` helper by making it return the stdout
output as a plain string (without extra properties) and re-throw any
errors (unless the `ignoreError` argument is set to `true`).
(Initially reported [here][1] by @JoostK.)
[1]: https://angular-team.slack.com/archives/C042EU9T5/p1608070403128900
PR Close#40161
Escape the content of the strings so that it can be safely inserted into a comment node.
The issue is that HTML does not specify any way to escape comment end text inside the comment.
`<!-- The way you close a comment is with "-->". -->`. Above the `"-->"` is meant to be text
not an end to the comment. This can be created programmatically through DOM APIs.
```
div.innerHTML = div.innerHTML
```
One would expect that the above code would be safe to do, but it turns out that because comment
text is not escaped, the comment may contain text which will prematurely close the comment
opening up the application for XSS attack. (In SSR we programmatically create comment nodes which
may contain such text and expect them to be safe.)
This function escapes the comment text by looking for the closing char sequence `-->` and replace
it with `-_-_>` where the `_` is a zero width space `\u200B`. The result is that if a comment
contains `-->` text it will render normally but it will not cause the HTML parser to close the
comment.
PR Close#40136
When building the environment stamp, support two modes: release and snapshot
The release mode will always stamp using the current version of in the root package.json
and in snapshot mode will use a version stamp expressing a version based on the tag and
the number of commits from the tag.
PR Close#40095
The vim editor produces temporarily files that can end in both .swo and
.swp. This commits add .swp to the .gitignore so we don't accidentaly
commit temporary files.
PR Close#40094
The `deploy-to-firebase.js` tests rely on git info retrieved from the
`angular/angular` repository (via `git ls-remote ...`).
Previously, different calls to `git ls-remote ...` could return
different values if a new commit was pushed or a new branch was created
during test execution, resulting in errors ([example CI failure][1]).
This commit makes the tests more stable by memoizing the result of
`git ls-remote ...` and returning the same result for subsequent calls
with the same arguments (even if meanwhile the remote has been updated).
[1]: https://circleci.com/gh/angular/angular/877626
PR Close#40088
Angular has stopped to support browser that requires these CSS properties.
All supported browsers support standard CSS properties:
* @keyframes rule
* animation
PR Close#40084
Removed rule don't affect their component views.
The reason - the templates don't contain elements to which that rule is applied.
See https://angular.io/guide/view-encapsulation for more details
PR Close#40080
With this change we update the CLI docs template to seperate
the following the default and value types from the argument field.
This should make it clearer and more understandable
PR Close#40038
Removed rules don't affect their component views.
The reason - the templates don't contain elements to which that rules are applied.
See https://angular.io/guide/view-encapsulation for more details
PR Close#40069
Angular has stopped to support browser that requires these CSS properties.
All supported browsers support standard CSS properties:
* border-radius
* border-bottom-left-radius
* border-bottom-right-radius
PR Close#40066
With regard to the code in `router_module.ts`, the correct equivalent for `enabled`
should be` enabledBlocking` and not `enabledNonBlocking`.
PR Close#40061
This commit moves the code for cleaning jqLite/jQuery data on an element
to a re-usable helper function. This way it is easier to keep the code
consistent across all places where we need to clean data (now and in the
future).
PR Close#40045
Angular has stopped to support browser that requires these CSS properties.
All supported browsers support standard box-sizing CSS property
PR Close#40039
Currently the compiler treats something like `{{ '{{a}}' }}` as a nested
binding and throws an error, because it doesn't account for quotes
when it looks for binding characters. These changes add a bit of
logic to skip over text inside quotes when parsing.
Fixes#39601.
PR Close#39826
Currently the code sample displayed in this guide is not a valid.
The `trigger` is directly used in the `@Component` decorator.
It should instead be in the `animations` array of the `@Component` decorator.
PR Close#37262
With the migration to husky@5, the environment variable used to skip husky changed from
`HUSKY_SKIP_HOOKS` to `HUSKY`. To continue skipping husky during the merge process as
expected, the environment variable used is updated.
PR Close#40025
Previously, due to the way the AngularJS and Angular clean-up processes
interfere with each other when removing an AngularJS element that
contains a downgraded Angular component, the data associated with the
host element of the downgraded component was not removed. This data was
kept in an internal AngularJS cache, which prevented the element and
component instance from being garbage-collected, leading to memory
leaks.
This commit fixes this by ensuring the element data is explicitly
removed when cleaning up a downgraded component.
NOTE:
This is essentially the equivalent of #26209 but for downgraded (instead
of upgraded) components.
Fixes#39911Closes#39921
PR Close#39965
The previous image referred to "Mr IQ". The example application
(and the content of the referring guide) actually uses "Dr IQ".
Closes#34823
PR Close#40022
The previous tutorial content referred to a `Routes` member of
`AppRoutingModule`, which is not correct. Instead there is a
`routes` variable that is passed to the `forRoot()` method when
configuring the `AppRoutingModule`.
Replaces #36583
PR Close#40023
1. In line 25 changed the word "components" to "component's".
2. In line 66 changed the phrase "you never refer to them" to "you should never refer to them".
3. Appended the paragraph containing the above phrase in a `div` with the class `alert is-helpful`.
PR Close#39246
Remove the statements where mentions the component in the `entryComponents`
array inside `NgModule` metadata.
This is not required since Angular version 9.
PR Close#39242
Aside from using the @input() decorator, we can use the @Attrbitute decorator too.
Of course, those two are different and support different causes.
I expected to see a working example on the Attribute Bindings section, but I didn't find one.
This PR depicts the usage of the Attribute decorator between two components
PR Close#38721
after angular version 8 string based lazy loading is not activated by default it is an opt in behaviour in which you have to add the lazy loaded routes in the tsconfig file for compilation. Aded a note too that it will be removed in version 11.
Fixes#35652
PR Close#35956
Add a TaggedTemplateExpr to represent tagged template literals in
Angular's syntax tree (more specifically Expression in output_ast.ts).
Also update classes that implement ExpressionVisitor to add support for
tagged template literals in different contexts, such as JIT compilation
and conversion to JS.
Partial support for tagged template literals had already been
implemented to support the $localize tag used by Angular's i18n
framework. Where applicable, this code was refactored to support
arbitrary tags, although completely replacing the i18n-specific support
for the $localize tag with the new generic support for tagged template
literals may not be completely trivial, and is left as future work.
PR Close#39122
Add test for when `checkTypeOfDomReferences = false` to ensure that we
do not regress in behavior at any point. The desired behavior for this
case is that the `TemplateTypeChecker` will honor the user's
configuration and not produce symbols for the dom reference.
PR Close#39539
Remove the check-env script as it is not longer relied on and only surfaces
false positives/known mismatches at this point.
Since our tooling now acts using vendored code where needed, this is no
longer as necessary as it previously was.
PR Close#39980
Previously, when a PR which does not target the master branch in the Github UI was
merged it would not close automatically. This change detects when this case occurs
and closes the PR via the Github API.
For example:
A PR which targets the 11.0.x branch in the Github UI has the `target: patch` label
This PR is only pushed into the 11.0.x branch, which does not trigger Github's
reference based actions to close the PR.
PR Close#39979
We intend to run the `@angular/upgrade` tests against all supported
versions of AngularJS (v1.5+). Previously, we only ran them against
v1.5, v1.6 and v1.7.
Since AngularJS v1.8 was released recently, this commit adds it to the
list of AngularJS versions we test against.
PR Close#39972
This commit adds `ngDevMode` guard to call `_ngModelWarning` only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The `ngDevMode` flag helps to tree-shake this function from production builds
(since it will act as no-op, in dev mode everything will work as it works right now)
to decrease production bundle size.
PR Close#39964
This commit adds ngDevMode guard to show warning only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The ngDevMode flag helps to tree-shake this warning from production builds
(in dev mode everything will work as it works right now) to decrease production bundle size.
PR Close#39964
This commit adds ngDevMode guard to show warnings only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The ngDevMode flag helps to tree-shake these warnings from production builds
(in dev mode everything will work as it works right now) to decrease production bundle size.
PR Close#39964
This commit adds `ngDevMode` guard to run `checkNoChanges` only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The `ngDevMode` flag helps to tree-shake this code from production builds
(in dev mode everything will work as it works right now) to decrease production bundle size.
PR Close#39964
When the compiler is invoked via ngc or the Angular CLI, its APIs are used
under the assumption that Angular analysis/diagnostics are only requested if
the program has no TypeScript-level errors. A result of this assumption is
that the incremental engine has not needed to resolve changes via its
dependency graph when the program contained broken imports, since broken
imports are a TypeScript error.
The Angular Language Service for Ivy is using the compiler as a backend, and
exercising its incremental compilation APIs without enforcing this
assumption. As a result, the Language Service has run into issues where
broken imports cause incremental compilation to fail and produce incorrect
results.
This commit introduces a mechanism within the compiler to keep track of
files for which dependency analysis has failed, and to always treat such
files as potentially affected by future incremental steps.
PR Close#39967
To avoid overwhelming a user with secondary diagnostics that derive from a
"root cause" error, the compiler has the notion of a "poisoned" NgModule.
An NgModule becomes poisoned when its declaration contains semantic errors:
declarations which are not components or pipes, imports which are not other
NgModules, etc. An NgModule also becomes poisoned if it imports or exports
another poisoned NgModule.
Previously, the compiler tracked this poisoned status as an alternate state
for each scope. Either a correct scope could be produced, or the entire
scope would be set to a sentinel error value. This meant that the compiler
would not track any information about a scope that was determined to be in
error.
This method presents several issues:
1. The compiler is unable to support the language service and return results
when a component or its module scope is poisoned.
This is fine for compilation, since diagnostics will be produced showing the
error(s), but the language service needs to still work for incorrect code.
2. `getComponentScopes()` does not return components with a poisoned scope,
which interferes with resource tracking of incremental builds.
If the component isn't included in that list, then the NgModule for it will
not have its dependencies properly tracked, and this can cause future
incremental build steps to produce incorrect results.
This commit changes the tracking of poisoned module scopes to use a flag on
the scope itself, rather than a sentinel value that replaces the scope. This
means that the scope itself will still be tracked, even if it contains
semantic errors.
PR Close#39967
Previously, if a trait's analysis step resulted in diagnostics, the trait
would be considered "errored" and no further operations, including register,
would be performed. Effectively, this meant that the compiler would pretend
the class in question was actually undecorated.
However, this behavior is problematic for several reasons:
1. It leads to inaccurate diagnostics being reported downstream.
For example, if a component is put into the error state, for example due to
a template error, the NgModule which declares the component would produce a
diagnostic claiming that the declaration is neither a directive nor a pipe.
This happened because the compiler wouldn't register() the component trait,
so the component would not be recorded as actually being a directive.
2. It can cause incorrect behavior on incremental builds.
This bug is more complex, but the general issue is that if the compiler
fails to associate a component and its module, then incremental builds will
not correctly re-analyze the module when the component's template changes.
Failing to register the component as such is one link in the larger chain of
issues that result in these kinds of issues.
3. It lumps together diagnostics produced during analysis and resolve steps.
This is not causing issues currently as the dependency graph ensures the
right classes are re-analyzed when needed, instead of showing stale
diagnostics. However, the dependency graph was not intended to serve this
role, and could potentially be optimized in ways that would break this
functionality.
This commit removes the concept of an "errored" trait entirely from the
trait system. Instead, analyzed and resolved traits have corresponding (and
separate) diagnostics, in addition to potentially `null` analysis results.
Analysis (but not resolution) diagnostics are carried forward during
incremental build operations. Compilation (emit) is only performed when
a trait reaches the resolved state with no diagnostics.
This change is functionally different than before as the `register` step is
now performed even in the presence of analysis errors, as long as analysis
results are also produced. This fixes problem 1 above, and is part of the
larger solution to problem 2.
PR Close#39967
This commit adds `ngDevMode` guard to show sanitization warnings only
in dev mode (similar to how things work in other parts of Ivy runtime code).
The `ngDevMode` flag helps to tree-shake these warnings from production builds
(in dev mode everything will work as it works right now) to decrease production bundle size.
PR Close#39959
This expands the deprecation message that started to pop up in v11.0.3
after the landing of commit e148382bd0,
that deprecated the `{[key: string]: any}` type for the options property of the `FormBuilder.group` method.
It turns out that having a custom validator declared as
`{ validators: (group: FormGroup) => ValidationErrors|null }` works in practice,
but is now inferred by TS as the deprecated version of `group`
(because `FormGroup` is a subclass of `AbstractControl` that `ValidatorFn` expects).
We considered the possibility of tweaking the forms API to accept such validators,
but it turns out to generate too many changes in the framework or possible breaking changes for Angular users.
We settled for a more explicit deprecation message, elaborated with the help of @petebacondarwin.
This will hopefully help developers to understand why the deprecation warning is showing up
when they think they are already using the non-deprecated overload.
PR Close#39946
In the past, the legacy (VE-based) language service would use a
`UrlResolver` instance to resolve file paths, primarily for compiler
resources like external templates. The problem with this is that the
UrlResolver is designed to resolve URLs in general, and so for a path
like `/a/b/#c`, `#c` is treated as hash/fragment rather than as part
of the path, which can lead to unexpected path resolution (f.x.,
`resolve('a/b/#c/d.ts', './d.html')` would produce `'a/b/d.html'` rather
than the expected `'a/b/#c/d.html'`).
This commit resolves the issue by using Node's `path` module to resolve
file paths directly, which aligns more with how resources are resolved
in the Ivy compiler.
The testing story here is not great, and the API for validating a file
path could be a little bit prettier/robust. However, since the VE-based
language service is going into more of a "maintenance mode" now that
there is a clear path for the Ivy-based LS moving forward, I think it is
okay not to spend too much time here.
Closes https://github.com/angular/vscode-ng-language-service/issues/892
Closes https://github.com/angular/vscode-ng-language-service/issues/1001
PR Close#39917
At the moment, when creating a root module, a subscription to the
`onError` subject is also created. It captures the scope where `NgModuleRef`
is created and prevents it from being garbage collected. Also note that this
`NgModuleRef` has a reference to the root module instance (e.g. `AppModule`),
which also prevents it from being GC'd.
PR Close#39940
Since #39853, it is possible to deploy to multiple Firebase sites from a
single branch. In order to deploy to a site, we need to associate an
alias (`aio`) with a site. This is done via the `firebase target:apply`
command. However, when the command is called multiple times, it
associates the alias with many sites, which subsequently fails during
deployment ([example failure][1]), since the `firebase deploy` command
does not know what site to deploy to.
This commit fixes the deployment script by ensuring that any previous
association with the `aio` alias is cleared (via the
`firebase target:clear` command) before associating it with a new site.
[1]: https://circleci.com/gh/angular/angular/871020
PR Close#39948
In the new behavior Angular removes applications from the testability registry when the
root view gets destroyed. This eliminates a memory leak, because before that the
TestabilityRegistry holds references to HTML elements, thus they cannot be GCed.
PR Close#22106
PR Close#39876
This commit adds a few tests to verify that the `onDestroy` callbacks are invoked when `ComponentRef` instance
is destroyed and the logic is consistent between ViewEngine and Ivy.
PR Close#39876
Fix a case where, if the parent class had already been patched, it would
not patch the child class. In addition to checking if the method is
defined in the prototype, and not inherited, it also does the same for
the unpatched method.
PR Close#39850
Previously, test descriptions used `latest` to refer to the most
recent/highest version. This was ambiguous, because `latest` can also
refer to the stable version of a package (e.g. see `@latest` npm tag).
This commit replaces `latest` with `highest` (or `highest for major`) to
reduce ambiguity.
Discussed in:
https://github.com/angular/angular/pull/39853#discussion_r531730317
PR Close#39853
Currently there is an issue with redirecting `rc.angular.io` to
`angular.io` when there is no active RC. If a user has visited
`rc.angular.io` before and has a ServiceWorker registered for that
subdomain, they will never "see" the redirect to `angular.io`.
This commit fixes the problem by doing an additional deployment from the
stable branch to the `rc-angular-io-site` Firebase site when there is no
active RC. This additional deployment will ensure that:
1. Users will be temporarily redirected from `rc.angular.io` to
`angular.io`.
2. Users with a registered ServiceWorker (who don't see the redirect)
will have their ServiceWorker unregistered on the next visit.
3. The content on both sites is identical.
See #39760 for more details on the problem and the solution.
NOTE:
As mentioned in #39760, for this fix to take affect, we need to remove
the redirect from `rc.angular.io` to `angular.io` in the Firebase
console for site `rc-angular-io-site`.
Fixes#39760
PR Close#39853
Previously, a branch would be deployed as `archive` even if it had a
major version that was equal/higher than that of the stable branch (as
long as it was not the RC branch - i.e. not the most recent minor
branch). For example, with `11.0.x` as the stable branch and `12.0.x`
as the RC branch, `11.1.x` would be deployed as archive.
Theoretically, we should never find ourselves in such a situation.
Typically, there will only be at most one minor branch most recent than
the stable one (and that branch will be the RC branch). However, it
is possible under unusual circumstances.
This commit adds additional checks to guard against this problem. It
also refactors the code in preparation of fixing an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker, which will
require identifying whether there is an active RC version or not.
See #39760 for more details.
PR Close#39853
Previously, the latest commit for branch may be computed multiple times
in the `deploy-to-firebase.js` tests.
This commit avoids the unnecessary re-computations by computing the
latest commits for the necessary branches at the beginning and using the
computed values throughout the tests.
PR Close#39853
Previously, the `deploy-to-firebase.js` script would only perform one
deployment operation on each run.
This commit adds support for performing multiple deployment operations.
NOTE:
In a subsequent commit, this will be leveraged fix an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker by
deploying the same artifacts to multiple Firebase projects/sites.
See #39760 for more details.
PR Close#39853
Previously, the `deploy()` function in `deploy-to-firebase.js` would
also perform other operations (beyond deploying), such as building the
app, checking the generated payload size, testing the PWA score of the
deployed app.
This commit decouples these operations, so that deploying can be
performed independently.
NOTE:
In a subsequent commit, this will be leveraged fix an issue with
`rc.angular.io` redirects in the presence of a ServiceWorker by
deploying the same artifacts to multiple Firebase projects/sites.
See #39760 for more details.
PR Close#39853
Since we turned off the Selenium Promise Manager in #39600, the AIO e2e
tests have started flaking on CI. After trying out several things, the
only change that seems to eliminate the flakiness is turning the
Selenium Promise Manager back on (see #39873 for more details).
This commit turns the Selenium Project Manager on to get rid of the
flakiness.
Fixes#39872
PR Close#39905
In #32497, an option was introduced to retry failed docs examples tests
a second time. This was done to work around some then recently
introduced flakiness. After inspecting ~50 recent CI docs examples jobs,
all tests passed on the first try.
This commit gets rid of the retry attempt. This will avoid covering up
any new flakiness introduces in the future.
PR Close#39905
This commit edits the copy on the interpolation page.
Tightens language, clarifies headers, and streamlines text.
There are no content or code changes.
PR Close#38687
Currently we convert objects to strings using `'' + value` which is quickest,
but it stringifies the value using its `valueOf`, rather than `toString`. These
changes switch to using `String(value)` which has identical performance
and calls the `toString` method as expected. Note that another option
was calling `toString` directly, but benchmarking showed it to be slower.
I've included the benchmark I used to verify the performance so we have it
for future reference and we can reuse it when making changes to `renderStringify`
in the future.
Also for reference, here are the results of the benchmark:
```
Benchmark: renderStringify
concat: 2.006 ns(0%)
concat with toString: 2.201 ns(-10%)
toString: 237.494 ns(-11741%)
toString with toString: 121.072 ns(-5937%)
constructor: 2.201 ns(-10%)
constructor with toString: 2.201 ns(-10%)
toString mono: 14.536 ns(-625%)
toString with toString mono: 9.757 ns(-386%)
```
Fixes#38839.
PR Close#39843
We currently only wrap the event listener in the function which ensures
ancestors are marked for check when the listener is placed on an element
that has a native method for listening to an event. We actually need to do
this wrapping in all cases so that events that are attached to non-rendered
template items (`ng-template` and `ng-container`) also mark ancestors for check
when they receive the event.
fixes#39832
PR Close#39833
DEPRECATION:
Mark the {[key: string]: any} type for the options property of the FormBuilder.group method as deprecated.
Using AbstractControlOptions gives the same functionality and is type-safe.
PR Close#39769
This adds angulararchitects.io to the tranings section in the
resources.json file for angular.io. It also adds a description
for angulararchitects.io.
PR Close#37139
The article previously referred was out of date. Most of the article content
was already duplicated here, or described how to generate multiple bundles. But
creating multiple bundles manually is now obsolete and the parameter `--localize`
should be preferred instead, because it is much faster.
This commit integrate the only interesting part left, relating to webserver configuration.
Co-authored-by: David Shevitz <dshevitz@google.com>
PR Close#36553
`en-US` makes it link to the English (US) version.
This patch removes this and let's MDN auto-redirect to the user's preferred/selected language/website locale.
PR Close#39842
For element queries that return sufficiently large NodeList
objects, using spread syntax to populate the results array
causes a RangeError due to the call stack limit being reached.
This commit updates the code to use regular "for" loop instead.
Fixes#38551.
PR Close#39646
This commit disables the Selenium Promise Manager when running e2e tests
for docs examples in order to more closely align them with new apps
created with CLI v11. This change requires that any async operations in
tests are handled explicitly (e.g. using `async/await` or
`Promise#then()`).
PR Close#39818
This commit removes some code that is no longer necessary for the
`upgrade-module` docs example e2e tests to run. It used to be necessary
in earlier version of Protractor but not any more.
PR Close#39818
Previously, the tests made no meaningful assertions. It seems that the
intention was to ensure that some elements were present on the page, but
all the assertions did was verify that the corresponding
`ElementFinder`s were defined. The `ElementFinder`s would always be
defined, even if there were no corresponding elements on the page. In
fact, some of the `ElementFinder` selectors were incorrect, so they did
not match any actual elements.
This commit fixes the tests by fixing the `ElementFinder` selectors and
asserting that the elements are actually present on the page.
PR Close#39818
Previously, the test made no meaningful assertion. It seems that the
intention was to ensure that some elements were present on the page, but
all the assertions did was verify that the corresponding
`ElementFinder`s were defined. The `ElementFinder`s would always be
defined, even if there were no corresponding elements on the page. In
fact, some of the `ElementFinder` selectors were incorrect, so they did
not match any actual elements.
This commit fixes the tests by fixing the `ElementFinder` selectors and
asserting that the elements are actually present on the page.
PR Close#39818
Addresses documentation gaps as reported in #35078. The documentation only
contained a single statement on foreign function/value compatibility
without going into detail on what this means. This commit adds several
examples to the Ivy compatibility guide and explains why Ivy behaves differently
compared to VE.
PR Close#36092
If a template declares a reference to a missing target then referring to
that reference from elsewhere in the template would crash the template
type checker, due to a regression introduced in #38618. This commit
fixes the crash by ensuring that the invalid reference will resolve to
a variable of type any.
Fixes#39744
PR Close#39805
Archives most of the content in the template expression operators doc.
The pipes precedence section that was originally in
template expression operators moves into the pipes doc
with some editing and an addition of a ternary example.
PR Close#39170
Since 5be4edfa17, a failing cache-busted
network request (such as requests for fetching uncached assets) will
cause the ServiceWorker to incorrectly enter a degraded
`EXISTING_CLIENTS_ONLY` mode. A failing network request could be caused
by many reasons, including the client or server being offline, and does
not necessarily signify a broken ServiceWorker state.
This commit fixes the logic in `cacheBustedFetchFromNetwork()` to
correctly handle errors in network requests.
For more details on the problem and the implemented fix see #39775.
Fixes#39775
PR Close#39786
Migrate the rebase-pr script used on CI out of tools and into the circleci
directory. Additionally removes its support for running in the local
repository as this is now better handled by `ng-dev pr rebase <pr-number>`.
PR Close#39592
The value of a `FormControl` is treated in a special way (called boxed values) when it's an object with exactly
2 fields: `value` and `disabled`. This commit adds a test which verifies that an object is not treated as a boxed
value when `disabled` field is present, but `value` is missing.
PR Close#39801
Currently all of our migrations are set up to find the tsconfig paths within a project,
create a `Program` out of each and migrate the files inside of the `Program`. The
problem is that the `Program` can include files outside of the project and the CLI
APIs that we use to interact with the file system assume that all files are within
the project.
These changes consolidate the logic, that determines whether a file can be migrated,
in a single place and add an extra check to exclude files outside of the root.
Fixes#39778.
PR Close#39790
When attempting to actually rely on `parseCommitMessagesForRange`, it became apparent
that the function really belongs in the parse file, rather than utils.
PR Close#39747
Edits copy and removes tokens and treeshaking
sections to reduce content duplication and keep
info focused. Moves provideParent() from di-navtree
to di providers.
PR Close#39403
We need to expose the declaration files for Ivy sources so that they can
be consumed by the Angular language server (`@angular/language-server`).
PR Close#39748
There are many places where examples use just a string for the command
in outlets. When using nested outlets, we do not correctly handle
this case, as the types and algorithm always expect an array.
This PR updates the `createUrlTree` algorithm to account for the
possibility of a string literal as the command for an outlet.
Fixes#18928
PR Close#39728
When parsing for i18n messages, interpolated strings are
split into `Text` and `Placeholder` pieces. The method that
does this `_visitTextWithInterpolation()` was becoming too
complex. This commit refactors that method along with some
associated functions that it uses.
PR Close#39717
When the `preserveWhitespaces` is not true, the template parser will
process the parsed AST nodes to remove excess whitespace. Since the
generated `goog.getMsg()` statements rely upon the AST nodes after
this whitespace is removed, the i18n extraction must make a second pass.
Previously this resulted in innacurrate source-spans for the i18n text and
placeholder nodes that were extracted in the second pass.
This commit fixes this by reusing the source-spans from the first pass
when extracting the nodes in the second pass.
Fixes#39671
PR Close#39717
`zone.js` 0.8.25 introduces `zone-testing` bundle and move all `fakeAsync/async` logic
from `@angular/core/testing` to `zone.js` package. But in case some user still using the old
version of `zone.js`, an old version of `fakeAsync/async` logic were still kept inside `@angular/core/testing`
package as `fallback` logic. Since now `Angular8+` already use `zone.js 0.9+`, so
those fallback logic is removed.
PR Close#37879
The codebase currently contains two `getOutlet` functions,
and they can end up in the bundle of an application.
A recent commit 6fbe21941d tipped us off
as it introduced several `noop` occurrences in the golden symbol files.
After investigating with @petebacondarwin,
we decided to remove the duplicated functions.
This probably shaves only a few bytes,
but this commit removes the duplicated functions,
by always using the one in `router/src/utils/config`.
PR Close#39764
While JavaScript does support implicit returns, it seems TypeScript will not infer the function return type from
the implicit return of the last statement (at least not in TS 3.4.3). So, when the `return` is missing from the
`get` function the implicit type of the function is `void`. So for the `get` function to be usable it needs to an
explicit return.
PR Close#31434
Occasionally, the SW would end up in a broken state where some of the
eagerly cached resources of an older version were available in the local
cache, but others (such as lazy-loaded bundles) were not. This would
leave the app in a broken state and a blank screen would be displayed.
See #28114 for a more detailed discussion.
This commit takes advantage of the newly introduced (in v11)
[SwUpdate#unrecoverable][1] API to detect these bad states and recover
by doing a full page reload whenever an [UnrecoverableStateEvent][2] is
emitted.
Partially addresses #28114.
NOTE:
Currently, `SwUpdate.unrecoverable` only works if the app has already
bootstrapped; i.e. if only lazy-loaded bundles have been purged from the
cache.
That should be fine in practice, since the cache entries are removed in
least-recently-used order. Thus the eagerly loaded bundles will be the
last to be removed from the cache (which rarely happens in practice).
[1]: https://v11.angular.io/api/service-worker/SwUpdate#unrecoverable
[2]: https://v11.angular.io/api/service-worker/UnrecoverableStateEvent
PR Close#39651
PR Close#39777
Previously, the `LocationService` depended on the `SwUpdatesService`.
This felt backwards, since `LocationService` is a more low-level and
basic service and should not be depending on a service for a
higher-level, specific feature (ServiceWorkers).
This commit inverses the relation, making `SwUpdatesService` depend on
`LocationService` instead.
PR Close#39651
PR Close#39777
Since we have a `MockLogger` class in `src/testing/`, there is no need
to create a new `MockLogger` class for the `SwUpdatesService` unit
tests.
This commit switches to using the `MockLogger` class from
`src/testing/`.
PR Close#39651
PR Close#39777
This commit fixes a bug when `Attribute` DI decorator is used in the
`deps` section of a token that uses a factory function. The problem
appeared because the `Attribute` DI decorator was not handled correctly
while injecting factory function attributes.
Closes#36479
PR Close#37085
Make sure that all Trusted Types-relevant sinks that can appear in an
Angular template (e.g. not <script>, since it's forbidden) continue to
work as expected with correct sanitization semantics, without
introducing Trusted Types violations.
PR Close#39614
- @angular dependencies point to ../../dist
- use absolute versions for other dependencies
- add a yarn.lock
- create ci-specific targets
- make karma and protractor use correct Chrome binary
PR Close#39614
Create an integration test for testing support for Trusted Types in Ivy.
Generated with:
```
yarn ng new ivy-trusted-types -g --skip-install --style css --routing --strict
```
PR Close#39614
The codebase currently contains several `noop` functions,
and they can end up in the bundle of an application.
A recent commit 6fbe21941d tipped us off
as it introduced several `noop` occurrences in the golden symbol files.
After investigating with @petebacondarwin,
we decided to remove the duplicated functions.
This probably shaves only a few bytes,
but this commit removes the duplicated functions,
by always using the one in `core/src/utils/noop`.
PR Close#39761
This commit updates the payload size limit for the AIO tests. This is likely an effect of the changes from
PR #39600 that was merged earlier.
PR Close#39766
In #38762 we added a migration to replace the deprecated `preserveQueryParams`
option with `queryParamsHandling`, however due to a typo, we ended up replacing it
with `queryParamsHandler` which is invalid.
Fixes#39755.
PR Close#39763
Removes duplicate info, moves document into conceptual
reference section, but doesn't edit remaining content.
Groups two dependency injection documents together in
one expandable nav section.
PR Close#39544
The 15.x versions of `yargs` relied upon a version of `y18n` that
has a SNYK vulnerability.
This commit updates the overall project, and therefore also the
`localize` and `compiler-cli` packages to use the latest version
of `yargs` that does not depend upon the vulnerable `y18n`
version.
The AIO project was already on the latest `yargs` version and so
does not need upgrading.
Fixes#39743
PR Close#39749
This commit fixes a confusing description of the `strictTemplates` flag.
> When `true`, enables strict template type checking in Angular version 9.
This seems to imply that the flag is only available in one version.
Strict template type checking is available in version 9 **and above**.
PR Close#39745
This commit downgrades `karma` to version 5.1.1, because of a regression
in version 5.2.0: karma-runner/karma#3560
It has been fixed with karma-runner/karma@05dc288016 on
master, but the fix is not included in the latest release (v5.2.3).
PR Close#39600
This commit updates `@angular/*` and `@angular/cli` (and related
packages) to version 11.0.0-rc.2. Apart from the automatic migrations,
this commit also tries to align `aio/` with new apps generated by the
latest CLI. (See [here][1] for a diff between a v10.1.3 and a
v11.0.0-rc.2 CLI app.)
[1]: https://github.com/cexbrayat/angular-cli-diff/compare/10.1.3...11.0.0-rc.2
PR Close#39600
Allowing command line arguments to provide the file and source values to
the restore-commit-message command will assist in the the process of
upgrading to husky@5.
PR Close#39739
This commit makes the breaking changes section of the v11.0.0 release
info in `CHANGELOG.md` easier to follow by:
1. Adding links to the corresponding commit for each breaking change (to
make it easier to find the full context of the change).
2. Turning breaking changes of each scope into a bulleted list (to make
it clearer that they affect the same package/scope).
NOTE:
It would be better if the changelog generation tooling handled this
automatically. This potential improvement is being tracked in #39698.
PR Close#39704
Usually, entries in the release notes for a version in `CHANGELOG.md` are
grouped by scope (i.e. all `compiler` changes together, all `router`
changes together, etc.). Currently, the notes for a non-patch release
are created manually, by contatenating the release notes for all
corresponding next/RC versions. As a result, the entries for v11.0.0 are
not grouped together.
This commit fixes it by grouping all entries for the v11.0.0 release by
scope, making it easier to identify all changes that affect a specific
package/scope.
PR Close#39704
It seems that the script used to generate the `CHANGELOG.md` content
incorrectly treats any link or issue/PR reference in the commit message
as a link to an issue fixed/closed by the commit. However, there are
cases where such links/references do not refer to issues fixed/closed by
the commit (or not refer to issues at all).
This commit fixes such bogus links in the v11.0.0 release info.
NOTE:
The underlying issue should be more generically addressed in the
changelog generation tooling. This is being tracked in #39698.
PR Close#39704
Currently, the script that is used to generate the `CHANGELOG.md`
content uses the first 7 characters of a commit SHA in the generated
links. This is problematic when there are multiple commits in the repo
(or forks of the repo?) that start with the same 7 characters (which is
rare but possible), since GitHub shows a 404 page.
This was the case with commit 736e0644b0
that is included in the v11.0.0 release notes and happens to start with
the same characters as commit 736e064ac80f5e0ed84711694c2ba68809222ffd.
This commit fixes the issue by using the full commit SHA in the link for
this particular commit.
NOTE:
The underlying issue should be more generically addressed in the
changelog generation tooling. This is being tracked in #39698.
PR Close#39704
Commit 4ca1c736bb (part of PR #38931) was
incorrectly marked with scope `packaging`, while it is an internal-only
change (i.e. it does not affect packaging). As such is should have been
marked with a different scope (for example, `ci`/`build`/`refactoring`)
and should not appear in `CHANGELOG.md`.
This commit removes the entry from `CHANGELOG.md` to avoid confusing
developers trying to understand how this change may affect their apps.
NOTE:
The commit contains a breaking change notice (about dropping support for
IE<11) which _is_ relevant to app developers. This breaking change
notice is preserved in the "BREAKING CHANGES" section, but the scope is
changes from `packaging` to `core` to avoid confusion.
PR Close#39704
This commit includes several minor fixes in the v11.0.0 release info in
`CHANGELOG.md`, such as:
- Fixing typos/punctuation.
- Making capitalization consistent.
- Wrapping code in backticks (for better readability).
PR Close#39704
Previously we hand coded the list of previous major versions
that are displayed in the left navigation.
Now these are generated from the tags in GitHub.
Closes#39688
PR Close#39689
Before this change, when trying to load a JSONP script that calls the JSONP callback inside a
microtask, it will fail in Internet Explorer 11 and EdgeHTML. This commit changes the onLoad cleanup
to be queued after the loaded endpoint executed any potential microtask itself. This ensures that
the aforementioned browsers will first evaluate the loaded script calling the JSONP callback and
only then run the cleanup inside onLoad.
Fixes#39496
PR Close#39512
ngNonBindable documentation was not present, on docs site added documentation for ngNonBindable. With this template primitive, Angular won't
evaluate expressions in elements.
Fixes#28577Fixes#19497
PR Close#36560
The result of utf-8 encoding a string was represented in a string, where
each individual character represented a single byte according to its
character code. All usages of this data were interested in the byte
itself, so this required conversion from a character back to its code.
This commit simply stores the individual bytes in array to avoid the
conversion. This yields a ~10% performance improvement for i18n message
ID computation.
PR Close#39694
Message ID computation makes extensive use of big integer
multiplications in order to translate the message's fingerprint into
a numerical representation. In large compilations with heavy use of i18n
this was showing up high in profiler sessions.
There are two factors contributing to the bottleneck:
1. a suboptimal big integer representation using strings, which requires
repeated allocation and conversion from a character to numeric digits
and back.
2. repeated computation of the necessary base-256 exponents and their
multiplication factors.
The first bottleneck is addressed using a representation that uses an
array of individual digits. This avoids repeated conversion and
allocation overhead is also greatly reduced, as adding two big integers
can now be done in-place with virtually no memory allocations.
The second point is addressed by a memoized exponentiation pool to
optimize the multiplication of a base-256 exponent.
As an additional optimization are the two 32-bit words now converted to
decimal per word, instead of going through an intermediate byte buffer
and doing the decimal conversion per byte.
The results of these optimizations depend a lot on the number of i18n
messages for which a message should be computed. Benchmarks have shown
that computing message IDs is now ~6x faster for 1,000 messages, ~14x
faster for 10,000 messages, and ~24x faster for 100,000 messages.
PR Close#39694
`ViewRef` and `ApplicationRef` had a circular reference. This change
introduces `ViewRefTracker` which is a subset of `ApplicationRef` for
this purpose.
PR Close#39710
JIT needs to identify which type is `ChangeDetectorRef`. It was doing so
by importing `ChangeDetectorRef` and than comparing the types. This creates
circular dependency as well as prevents tree shaking. The new solution is
to brand the class with `__ChangeDetectorRef__` so that it can be identified
without creating circular dependency.
PR Close#39710
`LContainer` stores `ViewRef`s this is not quite right as it creates
circular dependency between the two types. Also `LContainer` should not
be aware of `ViewRef` which iv ViewEngine specific construct.
PR Close#39710
Due to historical reasons `Injector.__NG_ELEMENT_ID__` was set to `-1`.
This changes it to be consistent with other `*Ref.__NG_ELEMENT_ID__`
constructs.
PR Close#39710
`Renderer2` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular
dependency between ViewEngine `Renderer2` which needs to declare `__NG_ELEMENT_ID__` and
ivy factory which needs to create it. The workaround used to be to pass the `Renderer2`
through stack but that created a very convoluted code. This refactoring simply bundles the
two files together and removes the stack workaround making the code simpler to follow.
PR Close#39710
`ChangeDetectorRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular
dependency between ViewEngine `ChangeDetectorRef` which needs to declare `__NG_ELEMENT_ID__` and
ivy factory which needs to create it. The workaround used to be to pass the `ChangeDetectorRef`
through stack but that created a very convoluted code. This refactoring simply bundles the
two files together and removes the stack workaround making the code simpler to follow.
PR Close#39710
`ViewContainerRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular
dependency between ViewEngine `ViewContainerRef` which needs to declare `__NG_ELEMENT_ID__` and
ivy factory which needs to create it. The workaround used to be to pass the `ViewContainerRef`
through stack but that created a very convoluted code. This refactoring simply bundles the
two files together and removes the stack workaround making the code simpler to follow.
PR Close#39710
`TemplateRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular
dependency between ViewEngine `TemplateRef` which needs to declare `__NG_ELEMENT_ID__` and
ivy factory which needs to create it. The workaround used to be to pass the `TemplateRef`
through stack but that created a very convoluted code. This refactoring simply bundles the
two files together and removes the stack workaround making the code simpler to follow.
PR Close#39710
`ElementRef` is declared in ViewEngine but it sub-classed in Ivy. This creates a circular
dependency between ViewEngine `ElementRef` which needs to declare `__NG_ELEMENT_ID__` and
ivy factory which needs to create it. The workaround used to be to pass the `ElementRef`
through stack but that created a very convoluted code. This refactoring simply bundles the
two files together and removes the stack workaround making the code simpler to follow.
PR Close#39710
Currently when we encounter an implicit method call (e.g. `{{ foo(1) }}`) and we manage to resolve
its receiver to something within the template, we assume that the method is on the receiver itself
so we generate a type checking code to reflect it. This assumption is true in most cases, but it
breaks down if the call is on an implicit receiver and the receiver itself is being invoked. E.g.
```
<div *ngFor="let fn of functions">{{ fn(1) }}</div>
```
These changes resolve the issue by generating a regular function call if the method call's receiver
is pointing to `$implicit`.
Fixes#39634.
PR Close#39686
This commit removes the TODO comment that proposed
that we use the built-in RxJS `isObservable()` function.
This is not a viable approach since the built-in function
requires that the `obj` contains additional methods that
our "observable" types (such as `EventEmitter`) do not
necessarily have.
See #39643 for more information.
PR Close#39669
With the update to our labeling scheme across the repository, the L2 triage
labels for PRs needs to be updated to no longer require a label type which
doesn't exist: `type: *`
PR Close#39655
`setComponentScope` was previously undocumented. This commit adds a short
explanation of what the function does, and adds a link to a doc which
explains issues with cycles in more detail.
PR Close#39662
ngtsc will avoid emitting generated imports that would create an import
cycle in the user's program. The main way such imports can arise is when
a component would ordinarily reference its dependencies in its component
definition `directiveDefs` and `pipeDefs`. This requires adding imports,
which run the risk of creating a cycle.
When ngtsc detects that adding such an import would cause this to occur, it
instead falls back on a strategy called "remote scoping", where a side-
effectful call to `setComponentScope` in the component's NgModule file is
used to patch `directiveDefs` and `pipeDefs` onto the component. Since the
NgModule file already imports all of the component's dependencies (to
declare them in the NgModule), this approach does not risk adding a cycle.
It has several large downsides, however:
1. it breaks under `sideEffects: false` logic in bundlers including the CLI
2. it breaks tree-shaking for the given component and its dependencies
See this doc for further details: https://hackmd.io/Odw80D0pR6yfsOjg_7XCJg?view
In particular, the impact on tree-shaking was exacerbated by the naive logic
ngtsc used to employ here. When this feature was implemented, at the time of
generating the side-effectful `setComponentScope` call, the compiler did not
know which of the component's declared dependencies were actually used in
its template. This meant that unlike the generation of `directiveDefs` in
the component definition itself, `setComponentScope` calls had to list the
_entire_ compilation scope of the component's NgModule, including directives
and pipes which were not actually used in the template. This made the tree-
shaking impact much worse, since if the component's NgModule made use of any
shared NgModules (e.g. `CommonModule`), every declaration therein would
become un-treeshakable.
Today, ngtsc does have the information on which directives/pipes are
actually used in the template, but this was not being used during the remote
scoping operation. This commit modifies remote scoping to take advantage of
the extra context and only list used dependencies in `setComponentScope`
calls, which should ameliorate the tree-shaking impact somewhat.
PR Close#39662
The resource loader uses TypeScript's module resolution system to
determine at which locations it needs to look for a resource file. A
marker string is used to force the module resolution to fail, such that
all failed lookup locations can then be considered for actual resource
resolution. Any filesystem requests targeting files/directories that
contain the marker are known not to exist, so no filesystem request
needs to be done at all.
PR Close#39604
The type alias allows for this pattern to be more easily used in other
areas of the compiler code. The current usages of this pattern have been
updated to use the type alias.
PR Close#39604
When a `ViewContainerRef` is injected, we dynamically create a comment node next to the host
so that it can be used as an anchor point for inserting views. The comment node is inserted
through the `appendChild` helper from `node_manipulation.ts` in most cases.
The problem with using `appendChild` here is that it has some extra logic which doesn't return
a parent `RNode` if an element is at the root of a component. I __think__ that this is a performance
optimization which is used to avoid inserting an element in one place in the DOM and then
moving it a bit later when it is projected. This can break down in some cases when creating
a `ViewContainerRef` for a non-component node at the root of another component like the following:
```
<root>
<div #viewContainerRef></div>
</root>
```
In this case the `#viewContainerRef` node is at the root of a component so we intentionally don't
insert it, but since its anchor element was created manually, it'll never be projected. This will
prevent any views added through the `ViewContainerRef` from being inserted into the DOM.
These changes resolve the issue by not going through `appendChild` at all when creating a comment
node for `ViewContainerRef`. This should work identically since `appendChild` doesn't really do
anything with the T structures anyway, it only uses them to reach the relevant DOM nodes.
Fixes#39556.
PR Close#39599
Currently when an instance of the `FormControlName` directive is destroyed, the Forms package invokes
the `cleanUpControl` to clear all directive-specific logic (such as validators, onChange handlers,
etc) from a bound control. The logic of the `cleanUpControl` function should revert all setup
performed by the `setUpControl` function. However the `cleanUpControl` is too aggressive and removes
all callbacks related to the onChange and disabled state handling. This is causing problems when
a form control is bound to multiple FormControlName` directives, causing other instances of that
directive to stop working correctly when the first one is destroyed.
This commit updates the cleanup logic to only remove callbacks added while setting up a control
for a given directive instance.
The fix is needed to allow adding `cleanUpControl` function to other places where cleanup is needed
(missing this function calls in some other places causes memory leak issues).
PR Close#39623
* Fixes that the Ivy styling logic wasn't accounting for `!important` in the property value.
* Fixes that the default DOM renderer only sets `!important` on a property with a dash in its name.
* Accounts for the `flags` parameter of `setStyle` in the server renderer.
Fixes#35323.
PR Close#39603
In #39470, the `deploy-to-firebase.sh` script (used to deploy AIO to
Firebase when building an upstream branch), was replaced by an
equivalent JS script. In this new `deploy-to-firebase.js` script, we
were overly aggressive with suppressing command output, which made it
hard to investigate failures ([example failing CI job][1]).
This commit updates the `deploy-to-firebase.js` script to capture
command output as usual in the CI job logs. This makes the output
similar to the one generated by the old [deploy-to-firebase.sh][2]
script ([example CI logs][3]).
One concern with capturing command output is having the value of a
secret environment variables leaked in the logs. This is not the case
here, since:
1. The secret env vars are not printed from the commands that use them.
2. CircleCI will [mask the values of secret env vars][4] in the output.
As an extra precaution (although not strictly necessary), we run `yarn`
with the `--silent` option, which avoid echoing the executed yarn
commands.
[1]: https://circleci.com/gh/angular/angular/849310
[2]: https://github.com/angular/angular/blob/3b0b7d22109c79b4dceb/aio/scripts/deploy-to-firebase.sh
[3]: https://circleci.com/gh/angular/angular/848109
[4]: https://circleci.com/docs/2.0/env-vars/#secrets-masking
PR Close#39596
The commit updates the AIO deployment script to also print the commit
SHA. This makes it easier to check whether a version has been
successfully deployed, by comparing the commit SHA from the CI job with
the SHA in the version string in the footer of the AIO app.
PR Close#39596
TCB generation occasionally transforms binding expressions twice, which can
result in a `BindingPipe` operation being `resolve()`'d multiple times. When
the pipe does not exist, this caused multiple OOB diagnostics to be recorded
about the missing pipe.
This commit fixes the problem by making the OOB recorder track which pipe
expressions have had diagnostics produced already, and only producing them
once per expression.
PR Close#39517
Previously, the project used for running integration tests for Angular
Elements declared a component that used `ShadowDom` for view
encopsulation, but it did not include any tests to verify that the view
was updated correctly.
This commit adds the missing tests.
PR Close#39452
`ComponentNgElementStrategy` is supposed to call `ngOnChanges()` on the
underlying component instance if available, but not fail if the
component does not have an `ngOnChanges()` method. This works as
expected. However, the test used to verify that was invalid; i.e. the
test would pass even if `ComponentNgElementStrategy` would try to call
`ngOnChanges()` on a component without such a method.
This commit replaces the invalid test with a new one that correctly
verifies that `ComponentNgElementStrategy` does not try to call
`ngOnChanges()`.
PR Close#39452
Previously, the `componentRef` property of `FakeComponentFactory` used
in `elements` tests was initialy set to a spy object with all mock
properties defined as spied methods. Later, the properties where
overwritten to the actual mock values.
This commit simplifies the creation of `componentRef` by correctly using
the arguments of [jasmine.createSpyObj()][1] to specify the desired
shape of the spy object (separating spied properties from methods and
directly providing the mock values).
[1]: https://jasmine.github.io/api/3.5/jasmine.html#.createSpyObj
PR Close#39452
In ViewEngine, SelfSkip would navigate up the tree to get tokens from
the parent node, skipping the child. This restores that functionality in
Ivy. In ViewEngine, if a special token (e.g. ElementRef) was not found
in the NodeInjector tree, the ModuleInjector was also used to lookup
that token. While special tokens like ElementRef make sense only in a
context of a NodeInjector, we preserved ViewEngine logic for now to
avoid breaking changes.
We identified 4 scenarios related to @SkipSelf and special tokens where
ViewEngine behavior was incorrect and is likely due to bugs. In Ivy this
is implemented to provide a more intuitive API. The list of scenarios
can be found below.
1. When Injector is used in combination with @Host and @SkipSelf on the
first Component within a module and the injector is defined in the
module, ViewEngine will get the injector from the module. In Ivy, it
does not do this and throws instead.
2. When retrieving a @ViewContainerRef while @SkipSelf and @Host are
present, in ViewEngine, it throws an exception. In Ivy it returns the
host ViewContainerRef.
3. When retrieving a @ViewContainerRef on an embedded view and @SkipSelf
is present, in ViewEngine, the ref is null. In Ivy it returns the parent
ViewContainerRef.
4. When utilizing viewProviders and providers, a child component that is
nested within a parent component that has @SkipSelf on a viewProvider
value, if that provider is provided by the parent component's
viewProviders and providers, ViewEngine will return that parent's
viewProviders value, which violates how viewProviders' visibility should
work. In Ivy, it retrieves the value from providers, as it should.
These discrepancies all behave as they should in Ivy and are likely bugs
in ViewEngine.
PR Close#39464
There is a compiler transform that downlevels Angular class decorators
to static properties so that metadata is available for JIT compilation.
The transform was supposed to ignore non-Angular decorators but it was
actually completely dropping decorators that did not conform to a very
specific syntactic shape (i.e. the decorator was a simple identifier, or
a namespaced identifier).
This commit ensures that all non-Angular decorators are kepts as-is
even if they are built using a syntax that the Angular compiler does not
understand.
Fixes#39574
PR Close#39577
Tokenized text node may have leading whitespace skipped from their
source-span. But the source-span is used to compute where there are
interpolated blocks, resulting in placeholder nodes whose source-spans
are offset by the amount of skipped characters.
This fix uses the `fullStart` location of text source-spans for computing
the source-span of placeholders, so that they are accurate.
Fixes#39195
PR Close#39486
This commit ensures that when leading whitespace is skipped by
the tokenizer, the original start location (before skipping) is captured
in the `fullStart` property of the token's source-span.
PR Close#39486
The lexer is able to skip leading trivia in the `start` location of tokens.
This makes the source-span more friendly since things like elements
appear to begin at the start of the opening tag, rather than at the
start of any leading whitespace, which could include newlines.
But some tooling requires the full source-span to be available, such
as when tokenizing a text span into an Angular expression.
This commit simply adds the `fullStart` location to the `ParseSourceSpan`
class, and ensures that places where such spans are cloned, this
property flows through too.
PR Close#39486
In an i18n message, two placeholders next to each other must have
an "empty" message-part to separate them. Previously, the source-span
for this message-part was pointing to the wrong original location.
This caused problems in the generated source-maps and lead to extracted
i18n messages from being rendered incorrectly.
PR Close#39486
Prior to this commit, the `cleanUpControl` function (responsible for cleaning up control instance)
was not taking validators into account. As a result, these validators remain registered on a detached
form control instance, thus causing memory leaks. This commit updates the `cleanUpControl` function
logic to also run validators cleanup.
As a part of this change, the logic to setup and cleanup validators was refactored and moved to
separate functions (with completely opposite behavior), so that they can be reused in the future.
This commit doesn't add the `cleanUpControl` calls to all possible places, it just fixes the cases
where this function is being called, but doesn't fully perform a cleanup. The `cleanUpControl`
function calls will be added to other parts of code (to avoid more memory leaks) in a followup PR.
PR Close#39234
When a class with a custom decorator is transpiled to ES5, it looks something like this:
```
var SomeClass = (function() {
function SomeClass() {...};
var SomeClass_1 = __decorate([Decorator()], SomeClass);
SomeClass = SomeClass_1;
return SomeClass;
})();
```
The problem is that if the class also has an Angular decorator that refers to the class itself
(e.g. `{provide: someToken, useClass: SomeClass}`), the generated `setClassMetadata` code will
be emitted after the IIFE, but will still refer to the intermediate `SomeClass_1` variable from
inside the IIFE. This happens, because we generate the `setClassMetadata` call directly from
the source AST which contains identifiers that TS will rename when it emits the ES5 code.
These changes resolve the issue by looking through the metadata AST and cloning any `Identifier`
that is referring to the class. Since TS doesn't have references to the clone, it won't rename
it when transpiling to ES5.
Fixes#39509.
PR Close#39527
When fetch is run in normal mode, the `git-fetch-pack` plumbing command
outputs progress to stderr. Since this is unnecessary progress
information for ng-dev usages, it should be suppressed instead.
PR Close#39503
The fw-testing group should only match on testing directories within the
framework packages, previously it was also matching in other areas of
the codebase.
PR Close#39536
Previously, the documentation for each major Angular version was hosted
on each own Firebase project. This required creating a new project for
each major release and increased the administrative/maintenance cost.
Now that Firebase supports hosting [multiple websites][1] as part of the
same project, we are switching to deploying all major versions to sites
created on `angular-io` project.
This is part of the work needed to prepare angular.io for our
[new versioning/branching process][2] (also tracked in #39366).
[1]: https://firebase.google.com/docs/hosting/multisites
[2]: https://docs.google.com/document/d/197kVillDwx-RZtSVOBtPb4BBIAw0E9RT3q3v6DZkykU
PR Close#39470
This commit breaks up the code in `deploy-to-firebase.js` script, that
we use for deploying angular.io to production, to smaller functions
(instead of a monolithic block). This makes the script easier to
maintain and also makes testing individual operations easier.
The commit also updates the `deploy-to-firebase.spec.js` spec file to
take advantage of the standalone functions to speed up testing by
calling the corresponding function instead of having to spawn a new
process and run the `deploy-to-firebase.js` script with the `--dry-run`
flag.
NOTE: Before updating the tests, I verified that the updated
`deploy-to-firebase.js` script passed the old tests.
PR Close#39470
Different deployment modes (such as `archive` and `next`) are identified
by the different colors used in prominent elements of the page, such as
the topbar and the footer.
Previously, the necessary styles for creating such a deployment mode
"theme" were duplicated for each mode.
This commit simplifies the creation/modification of a deployment mode
theme by introducing a Sass mixin that generates the necessary styles
(when provided with necessary theme colors).
PR Close#39470
Previously, the `deploy-to-firebase.js` script and the accompanying
`deploy-to-firebase.spec.js` spec file were using the `origin` remote
alias in certain commands. This works fine on CI, where `origin` points
to the `angular/angular` GitHub repo, but might not work locally.
This commit ensures that the correct remote is used by explicitly
specifying it by the URL, thus ensuring that the tests will behave
identically on CI and locally.
PR Close#39470
This commit switches the `deploy-to-firebase.sh` script, that we use for
deploying angular.io to production, from Bash to JavaScript. This makes
the script easier to maintain.
For the same reasons, it also switches the `deploy-to-firebase.test.sh`
script, that we use for testing the `deploy-to-firebase` script, from
Bash to JavaScript (using jasmine as the test runner).
Finally, this commit also updates ShellJS to the latest version to get
better error messages (including the actual error) when `exec()` fails.
NOTE: Before switching the test script to JS, I verified that the new
`deploy-to-firebase.js` script passed the tests with the old
`deploy-to-firebase.test.sh` script.
PR Close#39470
When registering an NgModule based on its id, all transitively imported
NgModules are also registered. This commit introduces a visited set to
avoid traversing into NgModules that are reachable from multiple import
paths multiple times.
Fixes#39487
PR Close#39514
The variable declaration for a template context is only needed when it
is referenced from somewhere, so the TCB operation to generate the
declaration is marked as optional.
PR Close#39321
When there is a primary outlet present in the outlets map and the object is also prefixed
with some other commands, the current logic only uses the primary outlet and ignores
the others. This change ensures that all outlets are respected at the
segment level when prefixed with other commands.
PR Close#39456
This commit has a small refactor of some methods in create_url_tree.ts
and adds some test cases, including two that will fail at the moment but
should pass. A follow-up commit will make use of the refactorings to fix
the test with minimal changes.
PR Close#39456
- Improves JSON formatting
- Add reference to font optimization
- Removes `="true"` from boolean command line args.
These are redundant and it can be confusing to why
boolean values need to be provided via a CLI.
PR Close#39427
Currently expressions `$event.foo()` and `this.$event.foo()`, as well as `$any(foo)` and
`this.$any(foo)`, are treated as the same expression by the compiler, because `this` is considered
the same implicit receiver as when the receiver is omitted. This introduces the following issues:
1. Any time something called `$any` is used, it'll be stripped away, leaving only the first parameter.
2. If something called `$event` is used anywhere in a template, it'll be preserved as `$event`,
rather than being rewritten to `ctx.$event`, causing the value to undefined at runtime. This
applies to listener, property and text bindings.
These changes resolve the first issue and part of the second one by preserving anything that
is accessed through `this`, even if it's one of the "special" ones like `$any` or `$event`.
Furthermore, these changes only expose the `$event` global variable inside event listeners,
whereas previously it was available everywhere.
Fixes#30278.
PR Close#39323
This commit updates the docs for the `tView.preOrderHooks` and `tView.preOrderCheckHooks` TView
fields. Current docs are not up-to-date as it was pointed out in #39439.
Closes#39439.
PR Close#39497
This is follow-up from [an earlier discussion](https://github.com/angular/angular/pull/39408#discussion_r511908358).
After some testing, it looks like the type of `Element.attributes` was correct in specifying that it
only has `TextAttribute` instances. This means that the extra checks that filter out `BoundAttribute`
instances from the array isn't necessary. There is another loop a bit further down that actually
extracts the bound i18n attributes.
PR Close#39498
Close#39296
Fix an issue that `markDirty()` will not trigger change detection.
The case is for example we have the following component.
```
export class AppComponent implements OnInit {
constructor(private router: Router) {}
ngOnInit() {
this.router.events
.pipe(filter((e) => e instanceof NavigationEnd))
.subscribe(() => ɵmarkDirty(this));
}
}
export class CounterComponent implements OnInit, OnDestroy {
ngOnInit() {
this.countSubject.pipe(takeUntil(this.destroy)).subscribe((count) => {
this.count = count;
ɵmarkDirty(this);
});
}
```
Then the app navigate from `AppComponent` to `CounterComponent`,
so there are 2 `markDirty()` call at in a row.
The `1st` call is from `AppComponent` when router changed, the
`2nd` call is from `CounterComponent.ngOnInit()`.
And the `markDirty()->scheduleTick()` code look like this
```
function scheduleTick(rootContext, flags) {
const nothingScheduled = rootContext.flags === 0 /* Empty */;
rootContext.flags |= flags;
if (nothingScheduled && rootContext.clean == _CLEAN_PROMISE) {
rootContext.schedule(() => {
...
if (rootContext.flags & RootContextFlags.DetectChanges)
rootContext.flags &= ~RootContextFlags.DetectChanges;
tickContext();
rootContext.clean = _CLEAN_PROMISE;
...
});
```
So in this case, the `1st` markDirty() will
1. set rootContext.flags = 1
2. before `tickContext()`, reset rootContext.flags = 0
3. inside `tickContext()`, it will call `CounterComponent.ngOnint()`,
so the `2nd` markDirty() is called.
4. and the `2nd` scheduleTick is called, `nothingScheduled` is true,
but rootContext.clean is not `_CLEAN_PROMISE` yet, since the `1st` markDirty tick
is still running.
5. So nowhere will reset the `rootContext.flags`.
6. then in the future, any other `markDirty()` call will not trigger the tick, since
`nothingScheduled` is always false.
So `nothingScheduled` means no tick is scheduled, `rootContext.clean === _CLEAN_PROMISE`
means no tick is running.
So we should set the flags to `rootContext` only when `no tick is scheudled or running`.
PR Close#39316
This commit updates the config of NgBot to treat tickets that have "needs clarification" or
"needs reproduction" labels on them as triaged.
PR Close#39494
This commit improves the ngModel docs, specifically:
- clarifies purpose of the name attribute in ngModelOptions
- clarifies on the interaction with a parent form or lack thereof
- fix inconsistency with analogy for two-way binding
- cleans up some typos and extra wordiness
- clarifies language around common properties
- adds missing preposition to commit message format origins
PR Close#39481
Some usages of the `GitClient` are better served by suppressing the
logging of lines that express what commands are being run. Many usages
of `GitClient` are contained within tools which are best served by
keeping the output clean as mostly read actions are occurring.
PR Close#39474
For better development experience of the dev-infra work, the `ng-dev:dev`
command runs the transpiled version of `ng-dev` making iterative
development easier.
PR Close#39474
The browser being launched needs to match the custom launcher name.
Otherwise Karma would still trigger the original Chrome executable without the flags.
PR Close#39480
Fixes#31186. This commit adds more context about the behavior
of template reference variables in nested templates and moves
doc into concepts section.
PR Close#31195
In the current release doc, we are using some shortcut of `git` command
such as `git ci` `git co`, so in this PR we are updating them
to the normal command, so these commands will work event without
these shortcuts.
PR Close#39442
Add the label `PullApprove: disable` as a caretaker note label to
prompt caretakers to confirm that the PullApprove disabling is
intentional.
PR Close#39430
Alowing for disabling PullApprove on a single PR via adding a label allows
for an escape hatch if PullApprove is not acting as expected, or for cases
where reviews can be stepped over in obvious situations, such as a revert.
PR Close#39430
adds RuntimeError and code enum to improve debugging experience
refactor ExpressionChangedAfterItHasBeenCheckedError to code NG0100
refactor CyclicDependency to code NG0200
refactor No Provider to code NG0201
refactor MultipleComponentsMatch to code NG0300
refactor ExportNotFound to code NG0301
refactor PipeNotFound to code NG0302
refactor BindingNotKnown to code NG0303
refactor NotKnownElement to code NG0304
PR Close#39188
This commit refactors validators-related logic that is common across most of the directives.
A couple notes on this refactoring:
* common logic was moved to the `AbstractControlDirective` class (including `validator` and
`asyncValidator` getters)
* sync/async validators are now composed in `AbstractControlDirective` class eagerly when validators
are set with `_setValidators` and `_setAsyncValidators` calls and the result is stored in directive
instance (thus getters return cached versions of validator fn). This is needed to make sure composed
validator function remains the same (retains its identity) for a given directive instance, so that
this function can be added and later removed from an instance of an AbstractControl-based class
(like `FormControl`). Preserving validator function is required to perform proper cleanup (in followup
PRs) of the AbstractControl-based classes when a directive is destroyed.
PR Close#38280
Update the cache keys used on CircleCI to bust the cache used in attempt
to address issue with tests on aio that are not reproducable locally.
Note: Going back to v1 as the cache version as caches are only held
for 15 days so we can safely return back to `v1` as the prefix
PR Close#39461
Currently render3's `parseTemplate` throws away the parsed AST and
returns an empty list of HTML nodes if HTML->R3 translation failed. This
is not preferrable in some contexts like that of a language service,
where we would like a well-formed AST even if it is has errors.
PR Close#39413
This reverts commit 561c0f81a0.
The original commit provided a quick escape from an already terminal
situation by killing the process if the PID in the lockfile was not
found in the list of processes running on the current machine.
But this broke use-cases where the node_modules was being shared between
multiple machines (or more commonly Docker containers on the same actual
machine).
Fixes#38875
PR Close#39435
Currently `i18n` attributes are treated the same no matter if they have data bindings or not. This
both generates more code since they have to go through the `ɵɵi18nAttributes` instruction and
prevents the translated attributes from being injected using the `@Attribute` decorator.
These changes makes it so that static translated attributes are treated in the same way as regular
static attributes and all other `i18n` attributes go through the old code path.
Fixes#38231.
PR Close#39408
This commit introduces two new methods to the TemplateTypeChecker, which
retrieve the directives and pipes that are "in scope" for a given component
template. The metadata returned by this API is minimal, but enough to power
autocompletion of selectors and attributes in templates.
PR Close#39278
This commit introduces caching of `Symbol`s produced by the template type-
checking infrastructure, in the same way that autocompletion results are
now cached.
PR Close#39278
This commit refactors the previously introduced `getGlobalCompletions()` API
for the template type-checker in a couple ways:
* The return type is adjusted to use a `Map` instead of an array, and
separate out the component context completion position. This allows for a
cleaner integration in the language service.
* A new `CompletionEngine` class is introduced which powers autocompletion
for a single component, and can cache completion results.
* The `CompletionEngine` for each component is itself cached on the
`TemplateTypeCheckerImpl` and is invalidated when the component template
is overridden or reset.
This refactoring simplifies the `TemplateTypeCheckerImpl` class by
extracting the autocompletion logic, enables caching for better performance,
and prepares for the introduction of other autocompletion APIs.
PR Close#39278
Ahead of upgrading to husky v5, adding the shell file location
to .gitignore to prevent it from randomly showing up when devs
checkout older branches. Beginning in v5, husky places its
shell files in a directory at `.husky/_` so these are placed
in the .gitignore to prevent being commited or tracked.
PR Close#39388
This commit removes a workaround to calculate the `expandoStartIndex` value. That workaround was needed
because the `expandoStartIndex` was updated previously, so it pointed at the wrong location. The problem
was fixed in PR #39301 and the workaround is no longer needed.
PR Close#39416
In production mode, the `ngDevMode` global may not have been declared.
This is typically not a problem, as optimizers should have removed all
usages of the `ngDevMode` variables. This does however require the
bundler/optimizer to have been configured in a certain way, as to allow
for `ngDevMode` guarded code to be removed.
As an example, Terser can be configured to remove the `ngDevMode`
guarded code using the following configuration:
```js
const terserOptions = {
// ...
compress: {
// ...
global_defs: require('@angular/compiler-cli').GLOBAL_DEFS_FOR_TERSER,
}
}
```
(Taken from https://github.com/angular/angular/issues/31595#issuecomment-519129090)
If this is not done, however, the bundle should still work (albeit with
larger code size due to missed tree-shaking opportunities). This commit
adds a check for whether `ngDevMode` has been declared, as it is a
top-level statement that executes before `ngDevMode` has been initialized.
Fixes#31595
PR Close#39415
The previous ViewEngine extraction tooling added `ctype` and `type`
attributes to XLIFF 1.2 and 2.0 translation files, respectively.
This commit adds this to the new $localize based extraction tooling.
Since the new extraction tooling works from the compiled output rather
than having direct access to the template content, the placeholder types
must be inferred from the name of the placeholder. This is considered
reasonable, since it already does this to compute opening and closing
tag placeholders.
Fixes#38791
PR Close#39398
Runtime i18n logic doesn't distinguish `<ng-content>` tag placeholders and regular element tag
placeholders in i18n messages, so there is no need to have a special marker for projection-based
placeholders and element markers can be used instead.
PR Close#39172
Due to how the global and sticky flag make RegExp objects stateful,
adds section detailing how it is not recommended
to use these flags for control validations.
PR Close#39055
The node hash bang was incidentally removed in the published ng-dev, it should
be included to allow for the command to be run without having to specify node.
PR Close#39443
Previously only the first message, for each id, was serialized
which meant that additional message location information
was lost.
Now all the message locations are included in the serialized
messages.
Fixes#39330
PR Close#39411
The `generateKeywords` dgeni processor automatically generates keywords
for each document by extracting words from each string property of a
`doc` object.
This commit adds `basePath` to the list of ignored properties, so that
it is _not_ considered when generating keywords. `basePath` mostly
contains the path to some root directory (such as
`/home/circleci/ng/packages`) and as such it does not contain useful
keywords.
For example, searching for `circleci` will match all API docs, because
it happens to be in the `basePath`:
https://v10.angular.io/?search=circleci
PR Close#39409
This commit improves the DefaultValueAccessor directive docs by:
- adding the `ngDefaultControl` as a search keyword to the description
- adding an example of the `ngDefaultControl` usage
Closes#35375.
PR Close#39404
Close#37531
Remove `global` declaration in `zone.ts` to avoid compile error when
upgrade to `@types/node` v12.12.68. Since the new type of global become
`NodeJS.global & typeof globalThis` and not compatible with `zone.ts` declaration.
PR Close#37861
Previously the volatile status file was always provided to the ng_rollup
action which prevented it from being cacheable remotely. This change to
only provide this file as an input when the --stamp flag is used will allow
for the action to be remotely cached and prevent needing to run the action
on every CI run.
PR Close#39392
The compiler uses a `Reference` abstraction to refer to TS nodes
that it needs to refer to from other parts of the source. Such
references keep track of any identifiers that represent the referenced
node.
Prior to this commit, the compiler (and specifically `ReferenceEmitter`
classes) assumed that the reference identifiers are always free standing.
In other words a reference identifier would be an expression like
`FooDirective` in the expression `class FooDirective {}`.
But in UMD/CommonJS source, a reference can actually refer to an "exports"
declaration of the form `exports.FooDirective = ...`.
In such cases the `FooDirective` identifier is not free-standing
since it is part of a property access, so the `ReferenceEmitter`
should take this into account when emitting an expression that
refers to such a `Reference`.
This commit changes the `LocalIdentifierStrategy` reference emitter
so that if the `node` being referenced is not a declaration itself and
is in the current file, then it should be used directly, rather than
trying to use one of its identifiers.
PR Close#39346
Previously, UMD/CommonJS class inline declarations of the form:
```ts
exports.Foo = (function() { function Foo(); return Foo; })();
```
were capturing the whole IIFE as the implementation, rather than
the inner class (i.e. `function Foo() {}` in this case). This caused
the interpreter to break when it was trying to access such an export,
since it would try to evaluate the IIFE rather than treating it as a class
declaration.
PR Close#39346
This commit updates the version of the `dev-infra/lock-closed` GitHub
action to the latest version, that includes the fix from
angular/dev-infra#80.
PR Close#39371
group together similar error messages as part of error code efforts
ProviderNotFound & NodeInjector grouped into throwProviderNotFoundError
Cyclic dependency errors grouped into throwCyclicDependencyError
PR Close#39251
There is no actionable change in this commit other than to pretty-print
EOF tokens. Actual parsing of unterminated pipes is already supported,
this just adds a test for it.
Part of #38596
PR Close#39113
Rather than running ng-dev via ts-node, going forward ng-dev is generated and run
locally via node. Additionally, the generated file is tested on each commit to
ensure that the local generated version stays up to date.
PR Close#39089
`TNode.insertBeforeIndex` is only populated when i18n is present. This
change puts all code which reads `insertBeforeIndex` behind a
dynamically loaded functions which are set only when i18n code executes.
PR Close#39301
The `ExpandoInstructions` was unnecessarily convoluted way to solve the
problem of calling the `HostBindingFunction`s on components and
directives. The code was complicated and hard to fallow.
The replacement is a simplified way to achieve the same thing, which
is also more efficient in space and speed.
PR Close#39301
`expandoInstructions` uses negative numbers by `-x`. This has lead to
issues in the paste as `-0` is processed as float rather than integer
leading to de-optimization.
PR Close#39233
IMPORTANT: `HEADER_OFFSET` should only be refereed to the in the `ɵɵ*` instructions to translate
instruction index into `LView` index. All other indexes should be in the `LView` index space and
there should be no need to refer to `HEADER_OFFSET` anywhere else.
PR Close#39233
- Made `*OpCodes` array branded for safer type checking.
- Simplify `I18NRemoveOpCodes` encoding.
- Broke out `IcuCreateOpCodes` from `I18nMutableOpCodes`.
PR Close#39233
`COMMENT_MARKER` is a generic name which does not make it obvious that
it is used for ICU use case. `ICU_MARKER` is more explicit as it is used
exclusively with ICUs.
PR Close#39233
When looking at `TView` debug template only Element nodes were displayed
as `TNode.Element` was used for both `RElement` and `RText`.
Additionally no text was stored in `TNode.value`. The result was that
the whole template could not be reconstructed. This refactoring creates
`TNodeType.Text` and store the text value in `TNode.value`.
The refactoring also changes `TNodeType` into flag-like structure make
it more efficient to check many different types at once.
PR Close#39233
Remove casting where we stored `TIcu` in `TNode.tagName` which was of
type `string` rather than `TIcu'. (renamed to `TNode.value` in previous
commit.)
PR Close#39233
Before this refactoring/fix the ICU would store the current selected
index in `TView`. This is incorrect, since if ICU is in `ngFor` it will
cause issues in some circumstances. This refactoring properly moves the
state to `LView`.
closes#37021closes#38144closes#38073
PR Close#39233
`TemplateFixture` used to have positional parameters and many tests got
hard to read as number of parameters reach 10+ with many of them `null`.
This refactoring changes `TemplateFixture` to take named parameters
which improves usability and readability in tests.
PR Close#39233
This commit fixes a bug when `useAbsoluteUrl` is set to true and
`ServerPlatformLocation` infers the base url from the supplied
`url`. User should explicitly set the `baseUrl` when they turn on
`useAbsoluteUrl`.
Breaking change:
If you use `useAbsoluteUrl` to setup `platform-server`, you now need to
also specify `baseUrl`.
We are intentionally making this a breaking change in a minor release,
because if `useAbsoluteUrl` is set to `true` then the behavior of the
application could be unpredictable, resulting in issues that are hard to
discover but could be affecting production environments.
PR Close#39334
Upgrade the karma dependency to version 4.4.0 in the root package.json
and in integration tests. Compared to version 4.3.0, which most of the
packages were previously depending on, it has the following changes:
Bug Fixes
- runner: remove explicit error on all tests failed
Features
- client: Add trusted types support
- Preprocessor can return Promise
- config: add failOnSkippedTests option.
- config: clientDisplayNone sets client elements display none.
- deps: Remove core-js dependency.
The motivation for upgrading the package is the Trusted Types support
that it adds, which is necessary to enable Trusted Types in Angular's
unit tests.
PR Close#39180
Revert back to downloading cldr-data directly as the npm package seems
to no longer be maintained and additionally, it carries a ~350mb cost
in our node modules that is unnecessarily downloaded by most developers
and on CI.
PR Close#39341
Perviously, it was not immediately clear what branches a PR would merge
into during the merge process. This prompt allows for caretakers to
understand and acknowledge where the PR will merge to.
PR Close#39333
Because the compiler-cli tests modify node_modules, this can cause
failures on windows CI specifically as node_modules are symlinked
to rather than copied. By running the test and build actions in
separate commands, all of the tests are built to be executed before
and tests are executed and modify the node_modules content.
PR Close#39289
Constructing a project service is expensive. Making it a singleton could
speed up tests considerably.
On my MacBook Pro, test execution went from 24.4s to 14.5s (~40% improvement).
PR Close#39308
Test harness `setup()` is expensive, in the order of ~2.5 seconds.
We could speed up `fit()` tests considerably if `setup()` is wrapped
in `beforeAll()` to avoid running it unnecessarily.
PR Close#39305
This commit edits the copy of the attribute binding documentation, moves the
colspan section that is primarily about property binding to the property
binding document, and adds a docregion to the attribute-binding
example to help clarify a point in the document.
Part of the copy edit reformats the style precedence list in tabular format
so that it is easier to read and understand.
PR Close#38860
This tool can be run from anywhere in the aio folder as:
```sh
yarn create-example <example-name>
```
It will create some basic scaffold files to get the example started.
After creation the developer should then use `yarn boilerplate:add`
or similar to ensure that the example can be run and tested.
You can optionally provide an absolute path to a pre-existing CLI
project and it will copy over appropriate files (ignoring boilerplate)
to the newly created example.
```sh
yarn create-example <example-name> /path/to/other/cli/project
```
Fixes#39275
PR Close#39283
When reading globals such as `ngDevMode` the read should be guarded by `typeof ngDevMode` otherwise it will throw if not
defined in `"use strict"` mode.
PR Close#36055
getCheckNoChangesMode was discovered to be unclear as to the purpose of
it. This refactor is a simple renaming to make it much clearer what that
method and property does.
PR Close#39277
When an input name is part of the directive selector, it would be good to return the directive as well
when performing 'go to definition' or 'go to type definition'. As an example, this would allow
'go to type definition' for ngIf to take the user to the NgIf directive.
'Go to type definition' would otherwise return no results because the
input is a generic type. This would also be the case for all primitive
input types.
PR Close#39243
Previously, temporary branches were created to be used for comparison to
the g3 branch, instead comparisons are now done using the branches
latest shas.
PR Close#39137
The Displaying Data in Views topic is actually a small tutorial
that describes Angular features such as interpolation and
structural directives. These content is already covered in
our getting started tutorial and in Tour of Heroes.
This change adds redirects to the Template Syntax section
of the Getting Started tutorial and deletes displaying-data.md.
PR Close#38885
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.
# VSCode Remote Development - Developing inside a Container
# VSCode Remote Development - Developing inside a Containers
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)
pendingDesc:"Googler: run g3sync presubmit {{PRNumber}}"
# text to show when the status is success
successDesc:'Does not affect google3'
successDesc:"Does not affect google3"
# link to use for the details
url:'http://go/angular/g3sync'
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/**"
- "dev-infra/benchmark/driver-utilities/**"
# 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!"
# label to monitor
mergeLabel: 'action:merge'
mergeLabel:"action: merge"
# adding any of these labels will also add the merge label
mergeLinkedLabels:
- 'action:merge-assistance'
- "action: merge-assistance"
# list of checks that will determine if the merge label can be added
checks:
# require that the PR has reviews from all requested reviewers
#
# This enables us to request reviews from both eng and tech writers, or multiple eng folks, and prevents accidental merges.
@@ -55,26 +100,34 @@ 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:*'
- "target: *"
- "cla: yes"
# list of labels that a PR shouldn't have, checked after the required labels with a regexp
forbiddenLabels:
- 'target:TBD'
- 'action:cleanup'
- 'action:review'
- 'state:blocked'
- "target: TBD"
- "action: cleanup"
- "action: review"
- "state: blocked"
- "cla: no"
# list of PR statuses that need to be successful
requiredStatuses:
- 'google-internal-tests'
- 'pullapprove'
- "ci/circleci: build"
- "ci/circleci: lint"
- "ci/circleci: publish_snapshot"
- "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 +137,40 @@ 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:*'
- - 'P1'
- 'area:*'
- - 'P2'
- 'area:*'
- - 'P3'
- 'area:*'
- - 'P4'
- 'area:*'
- - 'P5'
- 'area:*'
- - 'feature'
- 'area:*'
- - 'discussion'
- 'area:*'
- - 'needs clarification'
- 'area:*'
- - 'needs reproduction'
- 'area:*'
-
- "P0"
- "comp: *"
-
- "P1"
- "comp: *"
-
- "P2"
- "comp: *"
-
- "P3"
- "comp: *"
-
- "P4"
- "comp: *"
-
- "P5"
- "comp: *"
-
- "feature"
- "comp: *"
-
- "discussion"
- "comp: *"
-
- "needs clarification"
- "comp: *"
-
- "needs reproduction"
- "comp: *"
# options for the triage PR plugin
triagePR:
@@ -118,14 +182,16 @@ 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
l2TriageLabels:
- - 'area:*'
-
- "comp: *"
# options for rerunning CI
rerunCircleCI:
# set to true to disable
disabled:false
# the label which when added triggers a rerun of the default CircleCI workflow
'@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
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.
Andrew Scott
