Commit Graph

66 Commits

Author SHA1 Message Date
Paul Gschwendtner 6d35c5094a test(core): add test for template variable object property assignment (#29708)
The `template-var-assignment` schematic currently complains if someone
assigns a value to a template variable. This will no longer work with Ivy, but
it should be totally fine to update a property of the template variable if it refers
to an object. This commit adds a test that ensures that we don't incorrectly report
any failure for such property writes in bound events.

PR Close #29708
2019-04-08 09:46:57 -07:00
Paul Gschwendtner 4a2fb86b1e refactor(core): polish failure messages for template-var-assignment schematic (#29708)
Improves the failure messages for the `template-var-assignment` schematic. After manual
testing of the schematic it's not quite clear for developers what the failure message means
without any context. The schematic now also references a short markdown file mentioning
what needs to be changed, but eventually this document needs to be expanded with more
information and context of the reasoning behind this change within Ivy.

PR Close #29708
2019-04-08 09:46:57 -07:00
Filipe Silva 96b76dc3f1 fix(core): add missing migration to npm package (#29705)
While running `ng update @angular/core --next`, the following error would be displayed:

```
Cannot find module '....\node_modules\@angular\core\schematics\migrations\template-var-assignment\index'
```

This happened because the Schematics migration was referenced, but not included.

This commit fixes that bug by including the migration in the Bazel npm package dependencies.

PR Close #29705
2019-04-04 10:51:19 -07:00
Paul Gschwendtner 7c8f4e3202 feat(core): template-var-assignment update schematic (#29608)
Introduces a new update schematic called "template-var-assignment"
that is responsible for analyzing template files in order to warn
developers if template variables are assigned to values.

The schematic also comes with a driver for `tslint` so that the
check can be used wtihin Google.

PR Close #29608
2019-04-02 15:47:32 -07:00
Paul Gschwendtner 15eb1e0ce1 refactor(core): stronger type for resolved angular decorators (#29608)
PR Close #29608
2019-04-02 15:47:32 -07:00
Paul Gschwendtner 780081def0 refactor(core): move schematic typescript logic to utility package (#29608)
PR Close #29608
2019-04-02 15:47:32 -07:00
Paul Gschwendtner 33016b8929 fix(core): static-query schematic should detect static queries in getters. (#29609)
Queries can also be statically accessed within getters. e.g.

```ts
ngOnInit() {
  this.myQueryGetter.doSomething();
}
```

In that case we need to check if the `myQueryGetter` definition accesses
a query statically. As we need to use the type checker for every property acess
within lifecylce hooks, the schematic might become slower than before, but considering
that this is a one-time execution, it is totally fine using the type-checker extensively.

PR Close #29609
2019-04-01 10:58:51 -07:00
Paul Gschwendtner 09fab58109 fix(core): static-query schematic should detect queries in "ngDoCheck" and "ngOnChanges" (#29492)
Queries can be also used statically within the "ngDoCheck" and "ngOnChanges" lifecylce hook.
In order to properly detect all queries, we need to also respect these lifecycle hooks.

Resolves FW-1192

PR Close #29492
2019-03-25 09:21:35 -07:00
Paul Gschwendtner 4742385e95 refactor(core): fix misleading tslint schematic message (#29320)
Fixes the incorrect failure message or the TSLint rule that
is used within Google. The TSLint rule is not part of the
public schematic code.

Additionally in order to make it easier to understand what
action the developer needs to take, we rather print out the
expected "static: true/false" statement instead of saying that
a query needs to be static or dynamic. Dynamic is ambiguous, as
there is no `dynamic: true` option.

PR Close #29320
2019-03-18 17:37:45 -04:00
Paul Gschwendtner 90df7de54d refactor(core): better failure message for explicit-query timing tslint rule (#29258)
Improves the failure message for the `explicit-query` timing TSLint rule
that is used within Google. Currently it's not very clear what action
developers need to take in order to resolve the lint failure manually.

PR Close #29258
2019-03-14 16:02:37 -04:00
Paul Gschwendtner 8ef46f38f4 refactor(core): add tslint rule entry-point for static-query migration (#29258)
In order to be able to use the static-query migration logic within
Google, we need to provide a TSLint rule entry-point that wires up
the schematic logic and provides reporting and automatic fixes.

PR Close #29258
2019-03-14 16:02:37 -04:00
Paul Gschwendtner c5daaa91cf refactor(core): static-query schematic should not run multiple times (#29133)
With 6215799, we introduced a schematic for the new static-query timing.
Currently when someone runs the update schematic manually within his
CLI project (the schematic does not run automatically yet), he might have
noticed that the migration is executed for the same `tsconfig` file multiple
times. This can happen because the `getProjectTsConfigPaths` function
can incorrectly return the same tsconfig multiple times. The paths are not
properly deduped as we don't normalize the determined project tsconfig paths

PR Close #29133
2019-03-12 12:28:14 -07:00
Paul Gschwendtner 360730ce59 refactor(core): static-query migration does not detect external call expressions. (#29133)
Currently the static-query migration does not properly handle functions which
are declared externally. This is because we don't resolve the symbol of the
call-expression through its type. Currently we just determine the symbol of the
call-expression through the given call expression node, which doesn't necessarily
refer to the *value declaration* of the call expression. e.g. the symbol refers to the
import declaration which imports the external function. This means that we currently
can't check the external function as we couldn't find the actual value declaration.
We can fix this by resolving the type of the call expression and using the type in order
to retrieve the symbol containing the *value declaration*

PR Close #29133
2019-03-12 12:28:14 -07:00
Paul Gschwendtner fca1724ebf refactor(core): static-query schematic incorrectly handles multiple tsconfigs (#29133)
Currently when the static-query runs for a project with multiple TypeScript
configuration files (e.g. a usual CLI project), the migration incorrectly
applies the code transformation multiple times. This is because the migration
is currently based on the source file contents in the file system, while the
actual source file contents could have already changed in the devkit schematic
tree.

PR Close #29133
2019-03-12 12:28:14 -07:00
Paul Gschwendtner 3c53713616 refactor(core): static query schematic should handle asynchronous query usages properly (#29133)
With 6215799055, we introduced a schematic
for the Angular core package that automatically migrates unexplicit
query definitions to the explicit query timing (static <-> dynamic).

As the initial foundation was already big enough, it was planned
to come up with a follow-up that handles asynchronous query
usages properly. e.g. queries could be used in Promises,
`setTimeout`, `setInterval`, `requestAnimationFrame` and more, but
the schematic would incorrectly declare these queries as static.

This commit ensures that we properly handle these micro/macro
tasks and don't incorrectly consider queries as static.

The declaration usage visitor should only check the synchronous
control flow and completely ignore any statements within function
like expressions which aren't explicitly executed in a synchronous
way. e.g. IIFE's still work as the function expression is
synchronously invoked.

PR Close #29133
2019-03-12 12:28:14 -07:00
Paul Gschwendtner 6215799055 feat(core): update schematic to migrate to explicit query timing (#28983)
Introduces an update schematic for the "@angular/core" package
that automatically migrates pre-V8 "ViewChild" and "ContentChild"
queries to the new explicit timing syntax. This is not required
yet, but with Ivy, queries will be "dynamic" by default. Therefore
specifying an explicit query timing ensures that developers can
smoothly migrate to Ivy (once it's the default).

Read more about the explicit timing API here:
https://github.com/angular/angular/pull/28810

PR Close #28983
2019-03-05 14:21:40 -08:00