This should be `ngsw.json` not `ngsw-config.json` as the latter is only the src file that gets then compiled into the `ngsw.json` and placed into the `dist` folder
PR Close#28832
Prior to this commit, the timing of `ViewChild`/`ContentChild` query
resolution depended on the results of each query. If any results
for a particular query were nested inside embedded views (e.g.
*ngIfs), that query would be resolved after change detection ran.
Otherwise, the query would be resolved as soon as nodes were created.
This inconsistency in resolution timing had the potential to cause
confusion because query results would sometimes be available in
ngOnInit, but sometimes wouldn't be available until ngAfterContentInit
or ngAfterViewInit. Code depending on a query result could suddenly
stop working as soon as an *ngIf or an *ngFor was added to the template.
With this commit, users can dictate when they want a particular
`ViewChild` or `ContentChild` query to be resolved with the `static`
flag. For example, one can mark a particular query as `static: false`
to ensure change detection always runs before its results are set:
```ts
@ContentChild('foo', {static: false}) foo !: ElementRef;
```
This means that even if there isn't a query result wrapped in an
*ngIf or an *ngFor now, adding one to the template later won't change
the timing of the query resolution and potentially break your component.
Similarly, if you know that your query needs to be resolved earlier
(e.g. you need results in an ngOnInit hook), you can mark it as
`static: true`.
```ts
@ViewChild(TemplateRef, {static: true}) foo !: TemplateRef;
```
Note: this means that your component will not support *ngIf results.
If you do not supply a `static` option when creating your `ViewChild` or
`ContentChild` query, the default query resolution timing will kick in.
Note: This new option only applies to `ViewChild` and `ContentChild`
queries, not `ViewChildren` or `ContentChildren` queries, as those types
already resolve after CD runs.
PR Close#28810
Currently if developers use call expressions in their static
class members ([like we do in Angular](https://github.com/angular/angular/blob/master/packages/core/src/change_detection/differs/keyvalue_differs.ts#L121)),
the metadata that is generated for flat modules is invalid. This
is because the metadata bundler logic currently does not handle
call expressions in static class members and the symbol references
are not rewritten to avoid relative paths in the bundle.
Static class members using a call expression are not relevant for
the ViewEngine AOT compilation, but it is problematic that the
bundled metadata references modules using their original relative
path. This means that the bundled metadata is no longer encapsulated
and depends on other emitted files to be emitted in the proper place.
These incorrect relative paths can now cause issues where NGC
looks for the referenced symbols in the incorrect path. e.g.
```
src/
| lib/
| index.ts -> References the call expression using `../../di`
```
Now the metadata looks like that:
```
node_modules/
| @angular/
-- | core/
-- -- | core.metadata.json -> Says that the call expr. is in `../../di`.
| di/
```
Now if NGC tries to use the metadata files and create the summary files,
NGC resolves the call expression to the `node_modules/di` module. Since
the "unexpected" module does not contain the desired symbol, NGC will
error out.
We should fix this by ensuring that we don't ship corrupted metadata
to NPM which contains relative references that can cause such
failures (other imports can be affected as well; it depends on what
modules the developer has installed and how we import our call
expressions).
Fixes#28741.
PR Close#28762
In the TRIAGE_AND_LABELS doc, it was not clear that the merge label
may be applied by the author before the PR is green (as a sort of
auto-submit). After the label is applied, it is still up to the
caretaker to determine that the PR is acceptable before merging.
This commit adds that clarification.
PR Close#28837
As discussed in https://github.com/angular/angular/pull/28546#discussion_r254068014, we want to combine the
`define_env_vars` and `download_yarn` anchor since downloading Yarn depends on setting up the
environment variables. In addition this simplifies our setup and reduces code-duplication.
PR Close#28788
Previously, the `validate-commit-message` gulp task was using the
`git log ... ^r1 r2` syntax to list commits between the base branch and
the current head. This didn't work as expected on Windows, because `^`
is the escape character. As a result, the command was equivalent to
`git log ... r1 r2` on Windows, which essentially logs all commits
reachable from either `r1` or `r2`.
This commit fixes it by switching to git's
[double-dot range notation][1] (`r1..r2`), which is an alias for the
`^r1 r2` syntax and works correctly on all platforms.
[1]: https://git-scm.com/docs/gitrevisions#_dotted_range_notationsFixes#16830
PR Close#28780
Stop execution when an error happens in `validate-commit-message` gulp
task and ensure the error message is printed at the bottom.
Fixes#16829
PR Close#28780
Currently setting `enableIvy` to true runs a hybrid mode of `ngc` and `ngtsc`. This is counterintuitive given the name of the flag itself.
This PR makes the `true` value equivalent to the previous `ngtsc`, and `ngtsc` becomes an alias for `true`. Effectively this removes the hybrid mode as well since there's no other way to enable it.
PR Close#28616
Updating the doc to add the beginning label.
I'm not sure if this was the way it was intended, but it looked strange with just an ending </label> tag.
PR Close#28602
Previously, `ngtsc` detected class inheritance in a way that only worked
in TS or ES2015 code. As a result, inheritance would not be detected for
code in ES5 format, such as when running `ngtsc` through `ngcc` to
transform old-style Angular code to ivy format.
This commit fixes it by delegating class inheritance detection to the
current `ReflectionHost`, which is able to correctly interpret the used
code format.
PR Close#28773
This commit turns off an unknown binding test that is specific
to the View Engine implementation. In Ivy, we do property validation
at runtime for jit, so this test does not apply.
PR Close#28740
Accounts for schemas in when validating properties in Ivy.
This PR resolves FW-819.
A couple of notes:
* I had to rework the test slightly, in order to have it fail when we expect it to. The one in master is passing since Ivy's validation runs during the update phase, rather than creation.
* I had to deviate from the design in FW-819 and not add an `enableSchema` instruction, because the schema is part of the `NgModule` scope, however the scope is only assigned to a component once all of the module's declarations have been resolved and some of them can be async. Instead, I opted to have the `schemas` on the component definition.
PR Close#28637
Since we build and publish the individual packages
using Bazel and `build.sh` has been removed, we can
safely remove the `rollup.config.js` files which are no
longer needed because the `ng_package` bazel rule
automatically handles the rollup settings and globals.
PR Close#28646
Currently errors thrown inside event handler in Ivy are caught and forwarded to the `ErrorHandler`, however this means that if they happen during a unit test, the test won't fail. These changes add a test-specific `ErrorHandler` that throws the error rather than logging it out.
PR Close#28707
Previously `DebugNode.classes` and `DebugNode.styles` mistakenly used an
object that is only *sometimes* a `StylingContext`. Also fixes a mistake
in `debug_node_spec.ts` where a test component was not declared in the
testing module.
There is still a bug here where `DebugNode` is not exposing *static*
values. This will need to be fixed in a follow up.
PR Close#28709
Prior to this fix if a root component was instantiated it create host
bindings, but never render them once update mode ran unless one or more
slot-allocated bindings were issued. Since styling in Ivy does not make
use of LView slots, the host bindings function never ran on the root
component.
This fix ensures that the `hostBindings` function does run for a root
component and also renders the schedlued styling instructions when
executed.
Jira Issue: FW-1062
PR Close#28664
Under Bazel, some compilerOptions in tsconfig.json are controlled by
downstream rules. The default tsconfig.json causes Bazel to print out
warnings about overriden settings.
This commit makes a backup of the original tsconfig.json and removes
tsconfig settings that are controlled by Bazel.
As part of this fix, JsonAst utils are refactored into separate package
and unit tests are added.
PR closes https://github.com/angular/angular/issues/28034
PR Close#28674
BREAKING CHANGE
Previous to this change, when a control was reset, value and status change
events would be emitted before the control was reset to pristine. As a
result, if one were to check a control's pristine state in a valueChange
listener, it would appear that the control was still dirty after reset.
This change delays emission of value and status change events until after
controls have been marked pristine. This means the pristine state will be
reset as expected if one checks in a listener.
Theoretically, there could be applications depending on checking whether a
control *used to be dirty*, so this is marked as breaking. In these cases,
apps should cache the state on the app side before calling reset.
Fixes#28130
PR Close#28395
Juri Strumpflohner
Igor Minar
sis0k0
Trevor Karjanis
Kara Erickson
George Kalpakas
Paul Gschwendtner
Pawel Kozlowski
Amadou Sall
Nikita Potapenko
Filipe Silva
Jamie R. Rytlewski
Keilla Fernandes
Alan Agius
Sergej Grilborzer
Marc Laval
Adam Plumer
Cody Schroeder
Miško Hevery
Vani
Kristiyan Kostadinov
Jeremy Elbourn
Matias Niemelä
Keen Yee Liau
Greg Magolan
Artem Lanovyy
Alex Eagle