It's best to disable this optional migration in the minor release, although it shouldn't run anyway -- we don't want people accidentally running it.
This PR will be rolled back after the minor is out.
PR Close#44828
An `ng-template` with an inline template (i.e. has a structural
directive) would previously not get an `undefined` `tagName` because the
logic assumed the element would be `t.Element` or `t.Content` and read
the tag name from the `name` property. For a `t.Template`, this exists
instead on the `t.tagName`. The final result would be an `tagName` of `undefined`
for the parent `t.Template`, causing failures in the indexer downstream.
This `undefined` value is actually expected in the renderer code, even
though the type does not specify this possibility. This change updates
the type of `tagName` to be `string|null` and explicitly handles the
case where there is a structural directive on an `ng-template`. You can
see how the two are differentiated in the compliance code that was
modified in this commit.
PR Close#44788
* Update the UniqueAlterEgoValidator code example
* Add async-validator docregion to hero-form-reactive.component.2.ts
* Fix typo under Implementing a custom async validator
* Add h3 sections for adding async validators to reactive & template-driven forms
PR Close#44764
When setting up an async validator in a template-driven form, it's necessary to register the directive with NG_ASYNC_VALIDATORS instead of NG_VALIDATORS. This was not mentioned in the docs.
PR Close#44764
Add a new option for configuring data-groups, `cacheOpaqueResponses`,
that determines whether opaque responses are cached or not. This allows
greater flexibility in configuring the behavior of data-groups, while
still keeping the current defaults as fallbacks.
Fixes#44246
PR Close#44723
Make the `MockResponse` class used in tests behave more similarly to how
real responses work by making the following improvements:
- Use an empty `statusText` (`''`) when provided, instead of the default
`'OK'` value. This allows better representing opaque responses.
- Preserve more properties (`redirected`, `type`, `url`) when cloning a
`MockResponse`.
PR Close#44723
Update the "Service worker configuration" guide to mention the different
caching behaviors used for opaque responses based on the data-group's
configured strategy.
Related to #44246.
PR Close#44723
Modified required validator and checkbox validator to inherit abstractValidator.
For every validato type different PR will be raised as discussed in #42378.
Closes#42267
PR Close#44162
When the user opts into the noop `NgZone`, they usually still interact with the static methods on the non-noop class. This change adds a check to handle the case where zone.js hasn't been loaded.
Fixes#44784.
PR Close#44800
The previous fix for correcting spans with comments in
https://github.com/angular/angular/commit/59eef29a6c5d568ca80595cd7018e21ad406c85d
had the unfortunate side effect of _breaking_ the spans with comments
when there was leading whitespace. This happened because the previous
fix was testing one without a comment, identifying that the offset shouldn't
have anything added to it, and then removing that offset adjustment
(`offsets[i] + (expressionText.length - sourceToLex.length)`).
Upon further investigation, this offset adjustment _was actually
necessary_ for when the input had comments, but this was only because
the `stripComments` function used `trim` to remove whitespace for these
cases. This is the real problem -- not only does it create a ton of confusion
but also it means that the behavior of the lexer and resulting spans is
different between inputs with comments and inputs without comments.
After reviewing how the `inputLength` of `_ParseAST` was used, it
appears that the correct behavior would be to _not_ trim the input. The
`inputLength` is used to advance the current index beyond points which
have been processed. This _should_ include any whitespace. Additionally,
`inputLength` doesn't appear to be needed at all. When there was no
comment in the input, it was always equal to the `input.length` anyways.
When there _is_ a comment, it should include that comment anyways to
advance the index beyond the comment.
PR Close#44785
This includes the initial documentation for extended diagnostics with a page for each of the two initial checks. They follow the same general formula, and hopefully in the future they can be properly generated from metadata rather than copy-pasted as they are currently.
PR Close#44704
Refs #42966.
Look for changes in error docs (i.e. docs under `aio/content/error/`) in
`authors-package`, so that such docs are tracked when running the
`serve-and-sync` script.
PR Close#44704
Refs #42966.
Look for changes in error docs (i.e. docs under `aio/content/error/`) in
`authors-package`, so that such docs are tracked when running the
`serve-and-sync` script.
PR Close#44704
Related to #41434
Fix several flaky cases.
1. should restore `window.onerror` in test cases.
2. expect().toThrow() should pass a function.
PR Close#41526
When running tests with code coverage using Istanbul, the code is
instrumented with coverage reporting statements. These statements are
also inserted into synthesized constructors, preventing Angular from
properly recognizing them as synthesized constructor.
This commit changes the regex to detect synthesized constructors to allow
for statements within the constructor before the `super(...arguments);`
call. This is limited to code that does not contain a `}`, but this
is sufficient to support Istanbul's coverage instrumentation statements.
The tests have been extended with an input file that is being
instrumented using `babel-plugin-istanbul` for both ES2015 and ES5
targets, in order to verify that the approach works for real-world
usages.
Fixes#31337
PR Close#44732
Previously, if a bad extended diagnostic category was given, it would fail with the expected error as well as an unexpected assertion error:
```
$ ng build -c development
✔ Browser application bundle generation complete.
./src/main.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Unexpected call to 'assertNever()' with value:
test
at /home/douglasparker/Source/ng-new/node_modules/@ngtools/webpack/src/ivy/loader.js:77:18
at processTicksAndRejections (internal/process/task_queues.js:95:5)
./src/polyfills.ts - Error: Module build failed (from ./node_modules/@ngtools/webpack/src/ivy/index.js):
Error: Unexpected call to 'assertNever()' with value:
test
at /home/douglasparker/Source/ng-new/node_modules/@ngtools/webpack/src/ivy/loader.js:77:18
at processTicksAndRejections (internal/process/task_queues.js:95:5)
Error: error NG4004: Angular compiler option "extendedDiagnostics.checks['invalidBananaInBox']" has an unknown diagnostic category: "test".
Allowed diagnostic categories are:
warning
error
suppress
```
The assertion comes from `ExtendedTemplateCheckerImpl`, which expects a well-formed configuration, yet the compiler would construct it even when errors were found. This commit skips constructing and running extended diagnostics if the configuration had errors, which should avoid triggering these assertion errors.
I'm unfortunately not able to actually test this change. The test passes even before the fix because the `ngc` binary and end-to-end tests [don't request diagnostics unless the configuration is considered valid](https://github.com/angular/angular/blob/ed21f5c75378e1ce717ee3d76d28c8c994209de1/packages/compiler-cli/src/perform_compile.ts#L292-L293). See [Slack](https://angular-team.slack.com/archives/C4WHZQMRA/p1642641305003800) for more details.
PR Close#44778
`Renderer2` APIs expect to be called with the namespace name rather than
the namespace URI. Rather than passing around the URI and having to
account for different calling contexts, this change consistently uses
the namespace short names.
Importantly, the URI was only used in `component_ref.ts` `create`
(because `getNamespace returned the URIs`) and `createElementNode` in
`node_manipulation.ts` (because `getNamespaceUri` also used the URIs).
In contrast, attributes would use the _short names instead of URIs_
(see `setUpAttributes` in `attrs_utils.ts`). These names are pulled
directly from the attribute, i.e. `xhtml:href` and not converted to URI.
This dichotomy is confusing and unnecessary. The change here aligns the two
approaches in order to provide consistently throughout the system.
This relates to #44766 because the `createElementNode` was calling the
`AnimationRenderer.createElement` which delegates to the
`ServerRenderer`, which in turn was only set up to expect short names.
As a result, the `NAMESPACE_URIS` lookup failed and `Domino` created
the `svg` as a regular `Element` which does not have a `styles`
property.
resolves#44766
PR Close#44766
When the user wants to rename a symbol in the ts file VSCode
will ask the rename providers for the answer in turn. If the
first extension returns the result, the VSCode will break the
loop and apply the result. If the first extension cannot rename
the symbol, VSCode will ask the second extension in the
list (built-in TS/JS extension, Angular LS extension, etc.).
In other words, VSCode takes the result from only one rename provider
and the order depends on registration timing, scoring.
Because the built-in ts extension and Angular extension have the
same high score, if the built-in ts extension is the
first(depends on the time the extension was registered), the result
will be provided by the built-in extension. We want Angular to
provide it, so this plugin will delegate rename requests and reject
the request for the built-in ts server.
The Angular LS only provides the rename info when working within
an Angular project. If we cannot locate Angular sources in the
project files, the built-in extension should provide the rename info.
This plugin will apply to the built-in TS/JS extension and delegate
rename requests to the Angular LS. It provides the rename info only
when it is an Angular project. Otherwise, it will return info by the
default built-in ts server rename provider.
See [here][1] for more info.
[1]: https://github.com/microsoft/vscode/issues/115354
PR Close#44696
Refs #42966.
There were two remaining places where `_extendedTemplateDiagnostics` needed to be set which should have been removed in #44712 but got missed. This updates them to only require `strictTemplates` and not `_extendedTemplateDiagnostics` so the feature is properly enabled in production.
PR Close#44777
Mock dates in EventsComponent tests are parsed in inconsistent ways
across platforms/browsers, which makes the comparison to the mocked
UTC "now" date behave differently causing the test to fail. This fix
ensures that the mocked "now" date is parsed in the same way as the
test dates to avoid inconsistencies.
PR Close#44763
Refs #42966.
Extended diagnostics provide additional analysis about Angular templates by emitting warnings for specific patterns known to be error prone or cause developer confusion. Currently, there are two such diagnostics which are enabled by default:
* `invalidBananaInBox` emits a warning if a user writes a two-way binding backwards like `([foo])="bar"`, when they actually wanted `[(foo)]="bar"`.
* `nullishCoalescingNotNullable` emits a warning if a binding attempts to perform nullish coalescing (`??`) on a type which does not include `null` or `undefined`, such as `{{ foo ?? 'bar' }}` where `foo` is defined as `string` instead of `string | null`.
These diagnostics are enabled as warnings by default, but this can be configured in the `tsconfig.json` like so:
```jsonc
{
"angularCompilerOptions": {
"extendedDiagnostics": {
// The categories to use for specific diagnostics.
"checks": {
// Maps check name to its category.
"invalidBananaInBox": "suppress"
},
// The category to use for any diagnostics not listed in `checks` above.
"defaultCategory": "error"
}
}
}
```
Allowed categories for a diagnostic are `warning` (default), `error`, or `suppress`. `warning` emits the diagnostic but allows the compilation to succeed, `error` *will* fail the compilation, while `suppress` will ignore the diagnostic altogether.
The initial release has two diagnostics, and we are hoping to expand this longer term to add more diagnostics and provide additional insight into Angular templates to detect and surface developer mistakes *before* hours of debugging are wasted.
PR Close#44712
DEPRECATED:
Since Ivy, the CompilerOptions.useJit and CompilerOptions.missingTranslation config options are unused, passing them has no effect.
PR Close#44749
Andrew Kushnir