Commit Graph

43 Commits

Author SHA1 Message Date
Alan Agius 8b5ca670ad refactor(core): update migrations descriptions (#33440)
With the next version of the CLI we don't need to add logging for the description of the schematic as part of the schematic itself.

This is because now, the CLI will print the description defined in the `migrations.json` file.

See: https://github.com/angular/angular-cli/pull/15951

PR Close #33440
2019-10-28 17:07:50 -07:00
Kristiyan Kostadinov 7f6429d802 refactor: re-enable dynamic queries migration (#32992)
Re-enables the dynamic queries migration, now that we have all of the necessary framework changes in place.

Also moves the logic that identifies static queries out of the compiler and into the static queries migration, because that's the only place left that's using it.

PR Close #32992
2019-10-04 13:54:09 -07:00
Alan 01677b21b6 refactor(core): add `createMigrationCompilerHost` (#32827)
Current we need to create and override certain compiler host methods in every schematic because schematics use a virtual fs. We this change we extract this logic to a common util.

PR Close #32827
2019-10-04 11:45:35 -07:00
Paul Gschwendtner 7503e3540d refactor(core): static-queries migration should never use ngtsc (#32954)
ec4381d enabled Ivy by default. This is problematic as migrations
like `static-queries` depend on the `AngularCompilerProgram` (NGC)
in order to perform the migration from version 7 to version 8.

In order to ensure that the migration always runs with NGC
(and doesn't get the `NgtscProgram`), we need to explicitly disable
ivy when creating the `@angular/compiler-cli` program for the migration.

This code is still relevant even though the update from version 7
to version 8 landed. Developers can run `ng update` from version 7
and immediately get to version 9 where Ivy is enabled by default (and in
that case we need to ensure that ngtsc is not accidentally used).

Similar to
e5636a322c.

PR Close #32954
2019-10-02 14:53:41 -07:00
Paul Gschwendtner e4d5102b17 build: ensure schematics are built with typescript strict flag (#31967)
Follow-up to #30993 where we build all Angular packages with
the TypeScript `--strict` flag. The flag improves overall code
health and also helps us catch issues easier.

PR Close #31967
2019-08-13 11:39:00 -07:00
Paul Gschwendtner f69e4e6f77 refactor(core): move google3 migration rules into single directory (#30956)
Moves all google3 migration tslint rules into a single directory.
This makes it easier to wire up multiple migration rules in
google3 without having to update the rule directories each time
a new migration is available.

PR Close #30956
2019-07-23 15:52:40 -07:00
Alan Agius 80394ce08b fix(core): TypeScript related migrations should cater for BOM (#30719)
fix(@schematics/angular): TypeScript related migrations should cater for BOM

In the CLI `UpdateRecorder` methods such as `insertLeft`, `remove` etc.. accepts positions which are not offset by a BOM. This is because when a file has a BOM a different recorder will be used https://github.com/angular/angular-cli/blob/master/packages/angular_devkit/schematics/src/tree/recorder.ts#L72 which caters for an addition offset/delta.

The main reason for this is that when a developer is writing a schematic they shouldn't need to compute the offset based if a file has a BOM or not and is handled out of the box.

Example
```ts
recorder.insertLeft(5, 'true');
```

However this is unfortunate in the case if a ts SourceFile is used and one uses `getWidth` and `getStart` method they will already be offset by 1, which at the end it results in a double offset and hence the problem.

Fixes #30713

PR Close #30719
2019-05-30 20:48:45 -07:00
Paul Gschwendtner 6bf5ec241d docs(core): static-query migration should use permalink for migration guide (#30649)
8479cb4233 updated the static-query migration
to refer to the new guide on AIO. Unfortunately these URLs are currently not
valid as the guide is only available on `next.angular.io` right now. In order to
make the link work permanently (e.g. if we eventually remove the guide in future
major versions), we use the permalink from the `v8` subdomain.

PR Close #30649
2019-05-24 10:08:16 -05:00
Kara Erickson 8479cb4233 docs(core): update static query schematic with guide link (#30646)
PR Close #30646
2019-05-23 22:14:49 -07:00
Paul Gschwendtner 132c61dfd4 refactor(core): static-query migration should warn about syntax failures (#30628)
Currently if a project has source-files with syntax failures and the migration
has been started on a broken project, we silently migrate *as much as possible*,
but never notify the developer that the project was in a broken state and that
he can re-run the migration after the failures are fixed.

Additionally the template strategy does not need to exit gracefully if it detects
Angular semantic diagnostics on generated files (template type checking). These
diagnostics are not relevant for the query timing analysis.

PR Close #30628
2019-05-23 10:31:48 -07:00
Paul Gschwendtner 5640cedc82 refactor(core): static-query migration should always use template strategy (#30628)
We are removing the prompt for the `static-query` migration and make the
template strategy the migration strategy for the migration. The usage
strategy is good for best-practices, but for now we want to ensure that
the migration is a seamless as possible and that is only achievable my
re-using the same logic that View Engine uses for determining the
timing of a query.

PR Close #30628
2019-05-23 10:31:48 -07:00
Paul Gschwendtner 9e5377a2e3 refactor(core): improve messages for static-query migrations (#30458)
Slightly improves the messages for the static-query migration in order
to make the terminal output less verbose but more helpful. Unfortunately
we are limited in what we can print due to the devkit not providing much
utilities for printing good messages from a migration schematic.

PR Close #30458
2019-05-14 14:04:44 -07:00
Paul Gschwendtner 0cdf5980e2 fix(core): static-query migration should not fallback to test strategy (#30458)
Currently if something fails in the selected strategy (e.g. AOT failures),
the migration currently accidentally falls back to the test strategy. This
is not helpful as we want to give developers the possibility to re-run
the migration after fixing potential AOT failures.

PR Close #30458
2019-05-14 14:04:43 -07:00
Paul Gschwendtner 6ceb9034dc fix(core): static-query migration errors not printed properly (#30458)
Apparently the devkit logger is not able to properly print
out error objects, so we need to convert them to a string
before in order to make the error visible to the user.

This is not testable without an e2e test that validates the CLI
terminal output.

PR Close #30458
2019-05-14 14:04:43 -07:00
Alex Eagle 06efc340b6 build: update rules_nodejs and clean up bazel warnings (#30370)
Preserve compatibility with rollup_bundle rule.
Add missing npm dependencies, which are now enforced by the strict_deps plugin in tsc_wrapped

PR Close #30370
2019-05-14 10:08:45 -07:00
Paul Gschwendtner 8d3365e4fc fix(core): static-query usage migration strategy should detect ambiguous query usage (#30215)
Currently we always just set the timing to `false` if we aren't
able to analyze a given call expression or new expression. e.g.

```ts
ngOnInit() {
  thirdPartyCallSync(() => this.query.doSomething())
}
```

In that case the `thirdPartyCallSync` function comes from the `node_modules`
and is only defined through types while there is no code for the
actual function logic that can be analyzed. This makes it impossible
to tell whether the given call expression actually causes the specified
arrow function to be executed synchronously or not. In order to be able
to make this better, we now peek into the passed arrow function and
check for a synchronous query usage. If so, we set the query timing to
static and mark it as ambiguous. This ensures that the usage strategy is
less "magical" and more correct with third-party code.

Additionally since functions like `setTimeout` are not analyzable but known
to be asynchronous, there is a hard-coded list of known functions which
shouldn't be marked as ambiguous.

Resolves FW-1214. As planned within https://hackmd.io/hPiLWpPlQ4uynC1luIBdfQ

PR Close #30215
2019-05-09 14:39:06 -07:00
Paul Gschwendtner 0ffdb48f62 fix(core): static-query migration should handle queries on accessors (#30327)
Currently the static-query migration ignores queries declared on getters
or setters as these are not part of a `PropertyDeclaration`. We need to
handle these queries in order to cover all queries within a given project.

The usage strategy is not able to detect timing for queries on accessors,
so we add a TODO and print a message. The template strategy is able
to detect the proper timing for such queries because it's not dependent
on detecting the usage of the query.

Resolves FW-1215

PR Close #30327
2019-05-09 11:22:37 -07:00
Paul Gschwendtner 509352fc36 fix(core): static-query migration should gracefully exit if AOT compiler throws (#30269)
The static-query template strategy leverages the AOT compiler
in order to determine the query timing. Unfortunately the AOT
compiler has open bugs that can cause unexpected failures which
make the template strategy unusable in rare cases. These rare
exceptions need to be handled gracefully in order to avoid confusion
and to provide a more smooth migration.

Additionally migration strategy setup failures are now reported with
stack traces as the `ng update` command does not print stack traces.
This makes it easier to reproduce and report migration issues.

PR Close #30269
2019-05-08 11:54:33 -07:00
Paul Gschwendtner 349935a434 fix(core): migrations not always migrating all files (#30269)
In an Angular CLI project scenario where projects only reference
top-level source-files through the `tsconfig` `files` option, we currently
do not migrate referenced source-files. This can be fixed checking all
referenced source-files which aren't coming from an external library.

This is similar to how `tslint` determines project source-files.

PR Close #30269
2019-05-08 11:54:33 -07:00
Paul Gschwendtner 6357d4a0d3 fix(core): static-query migration fails with default parameter values (#30269)
Currently when someone has a call expression within the `ngOnInit` call
and we try to peek into that function with respect to the current function
context, the schematic errors because a call expression argument is
undefined. This is valid because the target function declaration defines
that parameter with a default value. In order to fix this, we need to
respect parameter default values.

PR Close #30269
2019-05-08 11:54:33 -07:00
Paul Gschwendtner 4c12d742dc fix(core): static-query migration should not prompt if no queries are used (#30254)
Currently we always prompt when the static-query migration runs. This is not
always needed because some applications do not even use `ViewChild` or
`ContentChild` queries and it just causes confusion if developers need to
decide on a migration strategy while there is nothing to migrate.

In order to avoid this confusion, we no longer prompt for a strategy
if there are no queries declared within the project.

PR Close #30254
2019-05-08 09:22:48 -07:00
Paul Gschwendtner 164d160b22 refactor(core): static-query migrations fails if options cannot be transformed (#30178)
Currently the `static-query` migrations fails at the final step of
updating a query when the query already specifies options which
cannot be transformed easily. e.g. the options are computed through
a function call: `@ViewChild(..., getQueryOpts());` or `@ViewChild(..., myOptionsVar)`.

In these cases we technically could add additionally logic to update
the query options, but given that this is an edge-case and it's
potentially over-engineering the migration schematic, we just
always add a TODO for the timing and print out the determined
query timing in the console. The developer in that case just needs
to manually update the logic for the query options to contain the
printed query timing.

Potentially related to: https://github.com/angular/angular-cli/issues/14298

PR Close #30178
2019-04-29 13:30:37 -07:00
Paul Gschwendtner 364250e7a6 refactor(core): static-query migration should not fail for test files (#30034)
Currently when someone runs `ng update` with the static-query migration,
the migration can fail with an error saying that the `AOT` compiler could not
be created. This can happen if the CLI project contains a test `tsconfig.json`
that is picked up by the schematic.

Due to the fact that spec tsconfig files cannot be ran with NGC (e.g. test
components are not part of a module; not all source files are guaranteed to
be included), test `tsconfig` projects will now use a new `test` migration
strategy where all queries within tests are left untouched and a TODO is added.

PR Close #30034
2019-04-23 08:32:35 -07:00
Paul Gschwendtner c1d5fbd0ad refactor(core): static-query template strategy should not parse stylesheets (#29876)
Currently the `template-strategy` for the static query migration uses the
Angular compiler in order to determine the query timing. This is problematic
as the AngularCompilerProgram also collects metadata for referenced
component stylesheets which aren't necessarily present. e.g. in a CLI
project the component can reference a Sass file. It's not guaranteed
that the standalone Angular compiler plugin supports Sass without
custom logic that is brought in by the Angular CLI webpack plugin.

In order to avoid any failures for invalid stylesheets, we just disable
normalizing of all referenced stylesheets.

PR Close #29876
2019-04-18 18:22:09 -07:00
Paul Gschwendtner ca591641c7 refactor(core): allow developers to select static-query migration strategy (#29876)
Currently there are two available migration strategies for the `static-query`
schematic. Both have benefits and negatives which depend on what the
developer prefers. Since we can't decide which migration strategy is the
best for a given project, the developer should be able to select a specific
strategy through a simple choice prompt.

In order to be able to use prompts in a migration schematic, we need to
take advantage of the "inquirer" package which is also used by the CLI
schematic prompts (schematic prompts are usually only statically defined
in the schema). Additionally the schematic needs to be made "async"
because with prompts the schematic can no longer execute synchronously
without implementing some logic that blocks the execution.

PR Close #29876
2019-04-18 18:22:09 -07:00
Paul Gschwendtner 446e3573e3 refactor(core): add static-query template strategy (#29815)
Introduces a new strategy for the `static-query` schematic that
is enabled by default. In order to provide a migration that works
for the most Angular applications and makes the upgrade as easy
as possible, the template strategy leverages the view engine
Angular compiler logic in order to determine the query timing
that is currently used within applications using view engine.

PR Close #29815
2019-04-15 10:53:54 -07:00
Paul Gschwendtner 205a45e9a8 refactor(core): move usage detection into usage strategy (#29815)
In order to support multiple strategies for detecting the query timing, the
query usage logic has been moved into a query usage strategy.

PR Close #29815
2019-04-15 10:53:53 -07:00
Paul Gschwendtner 5b32f55a3a refactor(core): static-query schematic should check templates (#29713)
Queries can technically be also accessed within component templates
e.g.

```html
<my-comp [binding]="myQuery"></my-comp>
```

In that case the query with the property "myQuery" is accessed
statically and needs to be marked with `static: true`. There are
other edge cases that need to be handled as the template property
read doesn't necessarily resolve to the actual query property.

For example:

```html
<foo #myQuery></foo>
<my-comp [binding]="myQuery"></my-comp>
```

In this scenario the binding doesn't refer to the actual query
because the template reference variable takes precedence. The
query doesn't need to be marked with "static: true" this time.

This commit ensures that the `static-query` migration schematic
now handles this cases properly. Also template property reads
that access queries from within a `<ng-template>` are ignored
as these can't access the query before the view has been initialized.

Resolves FW-1216

PR Close #29713
2019-04-11 08:22:44 -07:00
Bowen Ni faf8fdde14 refactor(core): Fix "explicit-query-timing" failure span. (#29792)
PR Close #29792
2019-04-11 07:40:10 -07:00
Paul Gschwendtner 4e8c2c3422 refactor(core): static-query schematic should handle abstract classes (#29688)
Queries can not only be accessed within derived classes, but also in
the super class through abstract methods. e.g.

```
abstract class BaseClass {

  abstract getEmbeddedForm(): NgForm {}

  ngOnInit() {
     this.getEmbeddedForm().doSomething();
  }
}

class Subclass extends BaseClass {
  @ViewChild(NgForm) form: NgForm;

  getEmbeddedForm() { return this.form; }

}
```

Same applies for abstract properties which are implemented in the base class
through accessors. This case is also now handled by the schematic.

Resolves FW-1213

PR Close #29688
2019-04-10 12:15:05 -07:00
Paul Gschwendtner 1102b02406 refactor(core): static-query schematic should handle function callbacks (#29663)
Currently the static-query schematic is not able to properly handle
call expressions that pass function declarations that access a given
query. e.g.

```ts
ngOnInit() {
  this._callFunction(() => this.myQuery.doSomething());
}

_callFunction(cb: any) { cb(); }
```

In that case the passed function is executed synchronously in
the "ngOnInit" lifecycle and therefore the query needs to be
detected as "static".

We can fix this by keeping track of the current function context
and using it to resolve identifiers to the passed arguments.

PR Close #29663
2019-04-08 17:21:24 -07:00
Paul Gschwendtner 00bf636afa refactor(core): static-query schematic should handle binary expressions (#29663)
Currently we only check getters for property access expressions. This is wrong
because property access expressions do not always cause the "getter" to be
triggered. e.g.

```ts
set a() {...}
get a() {...}

ngOnInit() {
  this.a = true;
}
```

In that case the schematic currently incorrectly checks the "getter", while this is a binary
expression and the property access is used as left-side of the binary expression. In that
case we need to check the setter declaration of the property and not the "getter". In order
to fix this, we need to also check `ts.BinaryExpression` nodes and check getters/setters
based on the used operator token. There are three types of binary expressions:

1) Value assignment (using `=`). In that case only the setter is triggered.
2) Compound assignment (e.g. using `+=`). In that case `getter` and `setter` are triggered.
3) Comparison (e.g. using `===`). In that case only the getter is triggered.

PR Close #29663
2019-04-08 17:21:24 -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 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