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
DEPRECATED:
The `CachedResourceLoader` and `RESOURCE_CACHE_PROVIDER` symbols were previously necessary in some cases to test AOT-compiled components with View Engine, but they are no longer needed since Ivy.
PR Close#44749
DEPRECATED:
The `ComponentFactory` and `ComponentFactoryResolver` classes are deprecated. Since Ivy, there is no need to resolve Component factories. Please use other APIs where you Component classes can be used directly (without resolving their factories).
PR Close#44749
update deprecated form of the tap operator. Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-arguments
DEPRECATED: tap operator subscribe signature is deprecated
Instead of passing separate callback arguments, use an observer argument. Signatures taking separate callback arguments will be removed in v8. Details: https://rxjs.dev/deprecations/subscribe-argumentsCloses#44708
PR Close#44738
Adds support for passing in an optional injector when creating an embedded view through `ViewContainerRef.createEmbeddedView` and `TemplateRef.createEmbeddedView`. The injector allows for the DI behavior to be customized within the specific template.
Fixes#14935.
PR Close#44666
errors in the animations code are of type `any` but are consistently
used as if there were `string`s, change `any` to `string` to make
typing more accurate
PR Close#44726
This implementation change was originally proposed as part of Typed Forms, and will have major consequences for that project as described in the design doc. Submitting it separately will greatly simplify the risk of landing Typed Forms. This change should have no visible impact on normal users of FormControl.
See the Typed Forms design doc here: https://docs.google.com/document/d/1cWuBE-oo5WLtwkLFxbNTiaVQGNk8ipgbekZcKBeyxxo.
PR Close#44316
The directive matching pass that happens during template compilation is
redundant, since directive matching has already happened during the resolution
phase of ngtsc and only matching declarables are provided to the template
compiler. In JIT mode the declarables only become available after the primary
template compilation has completed, so there is no need to perform directive
matching in both JIT and AOT mode.
PR Close#44731
This commit reduces the analysis work that needs to happen during an
incremental rebuild by properly recording files for which no traits were found
in the set of files that have no traits, such that the same file doesn't have
to be reanalyzed during subsequent rebuilds. It also excludes shim files from
analysis.
PR Close#44731
Bundlers like Rollup may use an element access expression for an export
declaration, which causes ngcc to ignore those export declarations possibly
resulting in incomplete processing of packages.
Element access syntax may be used when the declared name is not considered
as valid JS identifier, but bundlers may be conservative in determining whether
an identifier can be used (to emit a property access) and opt for a string
literal in an element access instead.
The element access syntax introduces a problem for ngcc, where it wouldn't
consider such export as class declaration, causing them to be skipped. The
ngtsc compiler is implemented with the assumption that all class declarations
use a `ts.Identifier` as name, whereas the element access is using a string
literal for the declared name. This makes it troublesome for ngcc to support
this syntax form in UMD bundles.
To work around the problem, this function transforms these access expressions
into regular property accesses. The source text is parsed to an AST to allow
finding the element accesses in a robust way, after which the affected text
ranges are replaced with property accesses in the original source text.
Closes#44037
PR Close#44669
The jasmine used in the docs is
```typescript
expect(<variableName>).<matcher>(predicate, failOutput)
```
The new version should be
```typescript
expect(<variableName>).withContext(failOutput).<matcher>(predicate)
```
So, this commit mainly focuses on changing the former to latter with
format below
```typescript
expect(<variableName>)
.withContext(failOutput)
.<matcher>(predicate)
```
And for RxJs, see https://rxjs.dev/deprecations/subscribe-arguments.
> For example someone could name functions poorly and confuse the next
reader: `source$.subscribe(doSomething, doSomethingElse, lol)` with that
signature, you have to know unapparent details about subscribe, where
using a partial observer solves that neatly: `source$.subscribe({ next:
doSomething, error: doSomethingElse, complete: lol }`).
This commit also does this conversion.
Last, remove the unused imported `async` from file
`twain.component.marbles.spec.ts`.
PR Close#44674
This new processor, named `mergeOverriddenImplementation`, allows Dgeni to produce correct documentation for symbols with overridden exported constructors. For example, in the following example, the implementation documentation will be used, including the constructor signature:
```
export const Foo: FooCtor = FooImpl as FooCtor;
```
This is a major improvement over the current situation, in which no constructor signature is documented whatsoever.
PR Close#44689
during keyframe building only consider the root element's timelines
for the style setting, so that the states styles (applied with '*')
can be applied correctly
resolves#32133resolves#28654
PR Close#44515
the createCustomEvent function's pupose is to create customEvents
even on browsers where `CustomEvent` is not a constructor,
`CustomEvent` is currently available in all supported browsers (since
IE11 support has ended), so remove the function as it is no longer
needed
PR Close#44703
Runtime error codes in the Core, Common and Forms packages were not included into the `public-api` group reviews. This commit creates the necessary golden files to keep track of further changes in the runtime codes.
This is a followup from https://github.com/angular/angular/pull/44398#issuecomment-1006910976.
PR Close#44677
Doug Parker