Commit Graph

95 Commits

Author SHA1 Message Date
Paul Gschwendtner d12cdb5019 fix(migrations): do not incorrectly add todo for @Injectable or @Pipe (#37732)
As of v10, the `undecorated-classes-with-decorated-fields` migration
generally deals with undecorated classes using Angular features. We
intended to run this migation as part of v10 again as undecorated
classes with Angular features are no longer supported in planned v11.

The migration currently behaves incorrectly in some cases where an
`@Injectable` or `@Pipe` decorated classes uses the `ngOnDestroy`
lifecycle hook. We incorrectly add a TODO for those classes. This
commit fixes that.

Additionally, this change makes the migration more robust to
not migrate a class if it inherits from a component, pipe
injectable or non-abstract directive. We previously did not
need this as the undecorated-classes-with-di migration ran
before, but this is no longer the case.

Last, this commit fixes an issue where multiple TODO's could be
added. This happens when multiple Angular CLI build targets have
an overlap in source files. Multiple programs then capture the
same source file, causing the migration to detect an undecorated
class multiple times (i.e. adding a TODO twice).

Fixes #37726.

PR Close #37732
2020-06-25 14:22:08 -07:00
Joey Perrott d1ea1f4c7f build: update license headers to reference Google LLC (#37205)
Update the license headers throughout the repository to reference Google LLC
rather than Google Inc, for the required license headers.

PR Close #37205
2020-05-26 14:26:58 -04:00
Paul Gschwendtner c6ecdc9a81 feat(core): undecorated-classes-with-decorated-fields migration should handle classes with lifecycle hooks (#36921)
As of v10, undecorated classes using Angular features are no longer
supported. In v10, we plan on removing the undecorated classes
compatibility code in ngtsc. This means that old patterns for
undecorated classes will result in compilation errors.

We had a migration for this in v9 already, but it looks like
the migration does not handle cases where classes uses lifecycle
hooks. This is handled in the ngtsc compatibility code, and we
should handle it similarly in migrations too.

This has not been outlined in the migration plan initially,
but an appendix has been added for v10 to the plan document.

https://hackmd.io/vuQfavzfRG6KUCtU7oK_EA?both.

Note: The migration is unable to determine whether a given undecorated
class that only defines `ngOnDestroy` is a directive or an actual
service. This means that in some cases the migration cannot do
more than adding a TODO and printing an failure.

Certainly there are more ways to determine the type of such classes,
but it would involve metadata and NgModule analysis. This is out of
scope for this migration.

PR Close #36921
2020-05-06 15:06:10 -07:00
Paul Gschwendtner 28995dba19 fix(core): missing-injectable migration should not migrate `@NgModule` classes (#36369)
Based on the migration guide, provided classes which don't have
either `@Injectable`, `@Directive`, `@Component` or `@Pipe` need
to be migrated.

This is not correct as provided classes with an `@NgModule` also
have a factory function that can be read by the r3 injector. It's
unclear in which cases the `@NgModule` decorator is used for
provided classes, but this scenario has been reported.

Either we fix this in the migration, or we make sure to report
this as unsupported in the Ivy compiler.

Fixes #35700.

PR Close #36369
2020-04-21 12:54:24 -04:00
Joey Perrott 698b0288be build: reformat repo to new clang@1.4.0 (#36613)
PR Close #36613
2020-04-14 12:08:36 -07:00
Paul Gschwendtner d43c30688a fix(core): avoid migration error when non-existent symbol is imported (#36367)
In rare cases a project with configured `rootDirs` that has imports to
non-existent identifiers could fail in the migration.

This happens because based on the application code, the migration could
end up trying to resolve the `ts.Symbol` of such non-existent
identifiers. This isn't a problem usually, but due to a upstream bug
in the TypeScript compiler, a runtime error is thrown.

This is because TypeScript is unable to compute a relative path from the
originating source file to the imported source file which _should_
provide the non-existent identifier. An issue for this has been reported
upstream: https://github.com/microsoft/TypeScript/issues/37731. The
issue only surfaces since our migrations don't provide an absolute base
path that is used for resolving the root directories.

To fix this, we ensure that we never use relative paths when parsing
tsconfig files. More details can be found in the TS issue.

Fixes #36346.

PR Close #36367
2020-04-06 13:21:54 -07:00
Paul Gschwendtner c24ad560fa feat(core): undecorated-classes migration should handle derived abstract classes (#35339)
In version 10, undecorated base classes that use Angular features need
to be decorated explicitly with `@Directive()`. Additionally, derived
classes of abstract directives need to be decorated.

The migration already handles this for undecorated classes that are
not explicitly decorated, but since in V9, abstract directives can be
used, we also need to handle this for explicitly decorated abstract
directives. e.g.

```
@Directive()
export class Base {...}

// needs to be decorated by migration when updating from v9 to v10
export class Wrapped extends Base {}

@Component(...)
export class Cmp extends Wrapped {}
```

PR Close #35339
2020-04-02 10:51:49 -07:00
Paul Gschwendtner 3d2db5c5f0 test: add integration test for undecorated-classes-with-decorated-fields migration (#35339)
We don't have an integration test for the `undecorated-classes-with-decorated-fields
migration. For consistency and to cover for the latest changes, we add
it to the `ng update` integration test.

PR Close #35339
2020-04-02 10:51:48 -07:00
Paul Gschwendtner 32eafef6a7 fix(core): undecorated-classes-with-decorated-fields migration does not decorate derived classes (#35339)
The `undecorated-classes-with-decorated-fields` migration has been
introduced with 904a2018e0, but misses
logic for decorating derived classes of undecorated classes which use
Angular features. Example scenario:

```ts
export abstract class MyBaseClass {
  @Input() someInput = true;
}

export abstract class BaseClassTwo extends MyBaseClass {}

@Component(...)
export class MyButton extends BaseClassTwo {}
```

Both abstract classes would need to be migrated. Previously, the migration
only added `@Directive()` to `MyBaseClass`, but with this change, it
also decorates `BaseClassTwo`.

This is necessary because the Angular Compiler requires `BaseClassTwo` to
have a directive definition when it flattens the directive metadata for
`MyButton` in order to perform type checking. Technically, not decorating
`BaseClassTwo` does not break at runtime.

We basically want to enforce consistent use of `@Directive` to simplify the
mental model. [See the migration guide](https://angular.io/guide/migration-undecorated-classes#migrating-classes-that-use-field-decorators).

Fixes #34376.

PR Close #35339
2020-04-02 10:51:48 -07:00
Paul Gschwendtner 2366480250 refactor(core): move schematic import manager to shared utils (#35339)
The import manager has been created for both the `missing-injectable`
and `undecorated-classes-with-di` migration. Both initial PRs brought
in the manager class, so the manager is duplicated in the schematics.

In order to reduce this duplication, and to expose the manager to other
schematics/migrations, we move it into the shared schematic utils.

PR Close #35339
2020-04-02 10:51:48 -07:00
Paul Gschwendtner 8e55a11283 refactor(core): move schematic base classes logic into shared utils (#35339)
Moves the `findBaseClassDeclarations` method into the shared
schematic utilities. This method will be useful for future
migrations, and for planned changes to the
`undecorated-classes-with-decorated-fields` migration.

PR Close #35339
2020-04-02 10:51:48 -07:00
Alex Rickabaugh 95c729f5d1 build: typescript 3.8 support (#35864)
This commit adds support in the Angular monorepo and in the Angular
compiler(s) for TypeScript 3.8. All packages can now compile with
TS 3.8.

For most of the repo, only a handful few typings adjustments were needed:

* TS 3.8 has a new `CustomElementConstructor` DOM type, which enforces a
  zero-argument constructor. The `NgElementConstructor` type previously
  declared a required `injector` argument despite the fact that its
  implementation allowed `injector` to be optional. The interface type was
  updated to reflect the optionality of the argument.
* Certain error messages were changed, and expectations in tests were
  updated as a result.
* tsserver (part of language server) now returns performance information in
  responses, so test expectations were changed to only assert on the actual
  body content of responses.

For compiler-cli and schematics (which use the TypeScript AST) a major
breaking change was the introduction of the export form:

```typescript
export * as foo from 'bar';
```

This is a `ts.NamespaceExport`, and the `exportClause` of a
`ts.ExportDeclaration` can now take this type as well as `ts.NamedExports`.
This broke a lot of places where `exportClause` was assumed to be
`ts.NamedExports`.

For the most part these breakages were in cases where it is not necessary
to handle the new `ts.NamedExports` anyway. ngtsc's design uses the
`ts.TypeChecker` APIs to understand syntax and so automatically supports the
new form of exports.

The View Engine compiler on the other hand extracts TS structures into
metadata.json files, and that format was not designed for namespaced
exports. As a result it will take a nontrivial amount of work if we want to
support such exports in View Engine. For now, these new exports are not
accounted for in metadata.json, and so using them in "folded" Angular
expressions will result in errors (probably claiming that the referenced
exported namespace doesn't exist).

Care was taken to only use TS APIs which are present in 3.7/3.6, as Angular
needs to remain compatible with these for the time being.

This commit does not update angular.io.

PR Close #35864
2020-03-10 17:51:20 -04:00
Paul Gschwendtner 59607dc495 fix(core): undecorated-classes-with-di migration should handle libraries generated with CLI versions past v6.2.0 (#35824)
The options for `flatModuleId` and `flatModuleOutFile` had been removed in the CLI
from generated libraries with 718ee15b9a.

This has been done because `ng-packagr` (which is used to build the
libraries) automatically set these options in-memory when it compiles the library.
No migration has been created for this because there was no actual need to get rid of
this. Keeping the options in the library `tsconfig` does not cause any problems unless
the `tsconfig` is used outside of `ng-packagr`. This was not anticipated, but is now
commonly done in `ng update` migrations.

The `ng update` migrations try to create an instance of the `AngularCompilerProgram` by
simply parsing the `tsconfig`. The migrations make the valid assumption that `tsconfig` files
are not incomplete/invalid. They _definitely_ are in the file system though. It just works for
libraries because `ng-packagr` in-memory completes the invalid `tsconfig` files, so that they
can be passed to the `@angular/compiler-cli`.

We can't have this logic in the `ng update` migrations because it's
out-of-scope for individual migrations to distinguish between libraries
and applications. Also it would be out-of-scope to parse the
`ng-packagr` configuration and handle the tsconfig in-memory completion.

As a workaround though, we can remove the flat-module bundle options
in-memory when creating the compiler program. This is acceptable since
we don't emit the program and the flat module bundles are not needed.

Fixes #34985.

PR Close #35824
2020-03-06 12:40:18 -05:00
Alex Rickabaugh 74edde0a94 perf(ivy): reuse prior analysis work during incremental builds (#34288)
Previously, the compiler performed an incremental build by analyzing and
resolving all classes in the program (even unchanged ones) and then using
the dependency graph information to determine which .js files were stale and
needed to be re-emitted. This algorithm produced "correct" rebuilds, but the
cost of re-analyzing the entire program turned out to be higher than
anticipated, especially for component-heavy compilations.

To achieve performant rebuilds, it is necessary to reuse previous analysis
results if possible. Doing this safely requires knowing when prior work is
viable and when it is stale and needs to be re-done.

The new algorithm implemented by this commit is such:

1) Each incremental build starts with knowledge of the last known good
   dependency graph and analysis results from the last successful build,
   plus of course information about the set of files changed.

2) The previous dependency graph's information is used to determine the
   set of source files which have "logically" changed. A source file is
   considered logically changed if it or any of its dependencies have
   physically changed (on disk) since the last successful compilation. Any
   logically unchanged dependencies have their dependency information copied
   over to the new dependency graph.

3) During the `TraitCompiler`'s loop to consider all source files in the
   program, if a source file is logically unchanged then its previous
   analyses are "adopted" (and their 'register' steps are run). If the file
   is logically changed, then it is re-analyzed as usual.

4) Then, incremental build proceeds as before, with the new dependency graph
   being used to determine the set of files which require re-emitting.

This analysis reuse avoids template parsing operations in many circumstances
and significantly reduces the time it takes ngtsc to rebuild a large
application.

Future work will increase performance even more, by tackling a variety of
other opportunities to reuse or avoid work.

PR Close #34288
2019-12-12 13:11:45 -08:00
Alan Agius d5aedbe892 refactor(core): update undecorated-classes-with-di migration rerun command (#33958)
With Angular CLI version 9 RC 3 we can run a single migration for a package using the name of the migration schematic.

We need to pass the schematic name as a value to the `migrate-only` option.
Ex:
```
ng update @angular/core --migrate-only migration-v9-undecorated-classes-with-di
```

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

PR Close #33958
2019-11-27 10:36:02 -08:00
Paul Gschwendtner 15fefdbb8d feat(core): missing-injectable migration should migrate empty object literal providers (#33709)
In View Engine, providers which neither used `useValue`, `useClass`,
`useFactory` or `useExisting`, were interpreted differently.

e.g.

```
{provide: X} -> {provide: X, useValue: undefined}, // this is how it works in View Engine
{provide: X} -> {provide: X, useClass: X}, // this is how it works in Ivy
```

The missing-injectable migration should migrate such providers to the
explicit `useValue` provider. This ensures that there is no unexpected
behavioral change when updating to v9.

PR Close #33709
2019-11-18 15:47:20 -08:00
Filipe Silva 1389d173fb fix(core): remove ngcc postinstall migration (#33727)
Partially address https://github.com/angular/angular-cli/issues/16017

PR Close #33727
2019-11-12 14:03:48 -08:00
Paul Gschwendtner d751ca7596 fix(core): renderer-to-renderer2 migration not migrating methods (#33571)
The `renderer-to-renderer2` migration currently does not work
properly in v9 because the migration relies on the type checker
for detecting references to `Renderer` from `@angular/core`.

This is contradictory since the `Renderer` is no longer
exported in v9 `@angular/core`. In order to make sure that
the migration still works in v9, and that we can rely on the
type checker for the best possible detection, we take advantage
of module augmentation and in-memory add the `Renderer` export
to the `@angular/core` module.

PR Close #33571
2019-11-05 22:05:17 +00:00
Paul Gschwendtner c0ad47a3fb fix(core): undecorated-classes-with-di migration should report config errors (#33567)
Currently TypeScript projects with an invalid tsconfig configuration,
cause the undecorated-classes-with-di migration to throw. Instead we
should gracefully exit the migration (like we do for syntactical
diagnostics), but report that there are configuration issues.

This issue surfaced when testing this migration in combination
with the Angular CLI migrations. One of the CLI migrations currently
causes invalid tsconfig files which then cause this issue in the
undecorated-classes-with-di migration.

PR Close #33567
2019-11-05 21:06:47 +00:00
Michael Prentice 5437e2da29 refactor(core): typo in undecorated-classes-with-di AOT failure message (#33018)
PR Close #33018
2019-11-04 16:07:26 +00:00
Paul Gschwendtner f197191a5f refactor(core): better error message for undecorated-classes-with-di migration (#33315)
Currently if one of the project targets could not be analyzed
due to AOT compiler program failures, we gracefully proceed
with the migration. This is expected, but we should not
print a message at the end of the migration that the migration
was _successful_. The migration was only done partially, hence
it's potentially incomplete and we should make it clear that once
the failures are resolved, the migration should be re-run.

PR Close #33315
2019-10-30 11:31:09 -07:00
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
Paul Gschwendtner 335854f6bc fix(core): missing-injectable migration should not update type definitions (#33286)
Currently the `missing-injectable` migration seems to add
`@Injectable()` to third-party classes in type definitions.

This not an issue in general since we do not generate broken code
by inserting a decorator into a type definition file. Though, we can
avoid adding the decorator since it won't have any effect and in
general we should not write to non source files of the compilation unit.

PR Close #33286
2019-10-25 13:26:00 -07:00
Paul Gschwendtner 4d23b60d09 fix(core): missing-injectable migration should not migrate providers with "useExisting" (#33286)
We should not migrate the reference from `useExisting`. This is because
developers can only use the `useExisting` value as a token. e.g.

```ts
@NgModule({
  providers: [
    {provide: AppRippleConfig, useValue: rippleOptions},
    {provide: MAT_RIPPLE_OPTIONS, useExisting: AppRippleConfig},
  ]
})
export class AppModule {}
```

In the case above, nothing should be decorated with `@Injectable`. The
`AppRippleConfig` class is just used as a token for injection.

PR Close #33286
2019-10-25 13:26:00 -07:00
Paul Gschwendtner eeecbf28e4 fix(core): missing-injectable migration should handle forwardRef (#33286)
Currently the migration is unable to migrate instances where
the provider definition uses `forwardRef`. Since this is a
common pattern, we should support that from within the migration.

The solution to the problem is adding a foreign function resolver
to the `PartialEvaluator`. This basically matches the usage of
the static evaluation that is used by the ngtsc annotations.

PR Close #33286
2019-10-25 13:26:00 -07:00
Kara Erickson a17cc9beee refactor(core): add links to remaining migration guides (#33385)
PR Close #33385
2019-10-24 16:21:49 -07:00
Adam Plumer 56731f624a feat(core): add ModuleWithProviders generic type migration (#33217)
Static methods that return a type of ModuleWithProviders currently
do not have to specify a type because the generic falls back to any.
This is problematic because the type of the actual module being
returned is not present in the type information.

Since Ivy uses d.ts files exclusively for downstream packages
(rather than metadata.json files, for example), we no longer have
the type of the actual module being created.

For this reason, a generic type should be added for
ModuleWithProviders that specifies the module type. This will be
required for all users in v10, but will only be necessary for
users of Ivy in v9.

PR Close #33217
2019-10-21 15:53:28 -04:00
Kara Erickson f289411fa9 docs(core): add migration guide links to schematics (#33258)
Angular v9 schematics should print out a link to the migration
guide associated with each schematic. This way, users have an
easy way to find more information about the automatic code
transformations they will see with `ng update`.

PR Close #33258
2019-10-18 18:18:37 -04:00
Filipe Silva 30d25f67af feat(core): add postinstall ngcc migration (#32999)
PR Close #32999
2019-10-15 17:54:38 +00:00
Paul Gschwendtner 5557dec120 refactor(core): missing-injectable migration should respect providers of directives and components (#33011)
Currenly the `missing-injectable` migration only migrates providers referenced from
`@NgModule` definitions. The schematic currently does not cover the migration for
providers referenced in `@Directive` or `@Component` definitions.

We need to handle the following keys for directives/components:

- `@Directive` -> `providers`
- `@Component` -> `providers` and `viewProviders`.

This commit ensures that the migration handles providers for these
definitions.

PR Close #33011
2019-10-14 20:24:01 +00: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
Keen Yee Liau adb562bca6 fix(language-service): create StaticReflector once only (#32543)
The creation of StaticReflector in createMetadataResolver() is a very expensive operation because it involves numerous module resolutions.
To make matter worse, since the API of the Reflector does not provide the ability to invalidate its internal caches, it has to be destroyed and recreated on *every* program change.
This has a HUGE impact on performance.
This PR fixes this problem by carefully invalidating all StaticSymbols in a file that has changed, thereby reducing the overhead of recomputation on program change.

PR Close #32543
2019-10-03 15:02:03 -07:00
Paul Gschwendtner 6f5f481fda refactor(core): undecorated-classes-with-di migration should ignore referenced resources (#32953)
Currently the undecorated-classes-with-di migration leverages NGC in order
to work with metadata resolution. Since NGC by default tries to resolve referenced
resources on initialization of the underlying TS program, it can result in unexpected
migration failures due to missing resource files.

This is especially an issue since the CLI wraps the `AngularCompilerProgram` with
special logic (i.e. to support SCSS preprocessing etc.). We don't have all of this since
we instantiate a vanilla NGC program.

The solution to the problem is to simply treat resource requests as valid, and returning
a fake content. The migration is not dependent on templates or stylesheets.. so it's the
simplest and most robust solution.

Fixes #32826

PR Close #32953
2019-10-02 14:54:33 -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
crisbeto f5982fd746 feat(core): add dynamic queries schematic (#32231)
Adds a schematic that will remove the explicit `static: false` flag from dynamic queries. E.g.

```ts
import { Directive, ViewChild, ContentChild, ElementRef } from '@angular/core';

@Directive()
export class MyDirective {
  @ViewChild('child', { static: false }) child: any;
  @ViewChild('secondChild', { read: ElementRef, static: false }) secondChild: ElementRef;
  @ContentChild('thirdChild', { static: false }) thirdChild: any;
}
```

```ts
import { Directive, ViewChild, ContentChild, ElementRef } from '@angular/core';

@Directive()
export class MyDirective {
  @ViewChild('child') child: any;
  @ViewChild('secondChild', { read: ElementRef }) secondChild: ElementRef;
  @ContentChild('thirdChild') thirdChild: any;
}
```

PR Close #32231
2019-09-11 19:14:03 -04:00
Paul Gschwendtner c56c2416a9 refactor(core): undecorated-classes-with-decorated-fields migration commits empty updates (#32391)
Commit 904a2018e0 introduced a new migration for
undecorated classes with decorated Angular class members. Currently the migration
always calls `tree.beginUpdate` and `tree.commitUpdate` (even if there are no changes).

This causes unnecessary updates to be reported to developers running `ng update`. Once
an update is commited, the CLI will report the update regardless of whether any changes were
made or not.

This behavior can be observed in the `ng_update_migrations` integration test. See:
https://circleci.com/gh/angular/angular/438470#tests/containers/3. Notice how all
source files are denoted as `UPDATED` (even though there are no changes).

PR Close #32391
2019-08-30 12:46:01 -07:00
Paul Gschwendtner 60a056d5dc refactor(core): undecorated classes migration should not decorate classes if not needed (#32319)
Currently the undecorated classes migration decorates base classes if no
explicit constructor is defined on all classes in the inheritance chain.

We only want to decorate base classes which define a constructor that is
inherited. Additionally for best practice, all classes in between the class
that inherits the constructor and the one that defines it are also decorated.

PR Close #32319
2019-08-28 17:11:36 -07:00
Paul Gschwendtner 543631f2b3 refactor(core): undecorated-classes migration should properly construct object literal from metadata (#32319)
The `undecorated-classes-with-di` migration currently creates invalid object literals from parsed
NGC metadata files if there are object literal properties with keys that contain special characters.

e.g. consider a decorated base class with a host binding using `[class.X]`. Currently the migration
parses and converts the metadata to TypeScript code but incorrectly uses `[class.X]` unquoted as
identifier.

PR Close #32319
2019-08-28 17:11:36 -07:00
Paul Gschwendtner e5636a322c refactor(core): undecorated-classes-with-di migration should never use ngtsc (#32318)
ec4381dd40 enabled Ivy by default. This is
problematic as migrations like `undecorated-classes-with-di` depend on the
`AngularCompilerProgram` (NGC) in order to perform the migration from
version 8 to version 9. 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.

PR Close #32318
2019-08-28 17:11:04 -07:00
Kristiyan Kostadinov 904a2018e0 feat(core): add undecorated classes with decorated fields schematic (#32130)
Adds a schematic that adds a `Directive` decorator to undecorated classes that have fields that use Angular decorators.

PR Close #32130
2019-08-22 10:05:38 -07:00
Paul Gschwendtner 639b732024 refactor(core): remove disabled injectable-pipe migration (#32184)
Initially the plan was to have a migration that adds `@Injectable()` to
all pipes in a CLI project so that the pipes can be injected in Ivy
similarly to how it worked in view engine.

Due to the planned refactorings which ensure that `@Directive`, `@Component`
and `@Pipe` also have a factory definition, this migration is no longer
needed for Ivy. Additionally since it is already disabled (due to
572b54967c) and we have a more generic
migration (known as `missing-injectable)` that could do the same as
`injectable-pipe`, we remove the migration from the code-base.

PR Close #32184
2019-08-19 15:44:02 -07:00
Paul Gschwendtner 024c31da25 feat(core): add undecorated classes migration schematic (#31650)
Introduces a new migration schematic that follows the given
migration plan: https://hackmd.io/@alx/S1XKqMZeS.

First case: The schematic detects decorated directives which
inherit a constructor. The migration ensures that all base
classes until the class with the explicit constructor are
properly decorated with "@Directive()" or "@Component". In
case one of these classes is not decorated, the schematic
adds the abstract "@Directive()" decorator automatically.

Second case: The schematic detects undecorated declarations
and copies the inherited "@Directive()", "@Component" or
"@Pipe" decorator to the undecorated derived class. This
involves non-trivial import rewriting, identifier aliasing
and AOT metadata serializing
(as decorators are not always part of source files)

PR Close #31650
2019-08-13 14:40:52 -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 9896d438c0 refactor(core): move renderer2 migration lint rule into google3 folder (#31817)
Moves the `renderer_to_renderer2` migration google3 tslint rule
into the new `google3` directory. This is done for consistency
as we recently moved all google3 migration rules into a new
`google3` folder (see: f69e4e6f77).

PR Close #31817
2019-08-09 10:46:45 -07:00
Paul Gschwendtner 684579b338 build: create google3 migration tests bazel target (#31817)
Creates a separate bazel target for the google3 migration
tests. The benefit is that it's faster to run tests for
public migrations in development. Google3 lint rules are
usually another story/implementation and the tests are quite
slow due to how TSLint applies replacements.

Additionally if something changes in the google3 tslint rules,
the tests which aren't affected re-run unnecessarily.

PR Close #31817
2019-08-09 10:46:45 -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
Paul Gschwendtner 9f2ae5d6ff feat(ivy): introduce missing-injectable migration for google3 (#30956)
Introduces a new migration schematic for adding the "@Injectable()"
decorator to provider classes which are currently not migrated. Previously
in ViewEngine, classes which are declared as providers sometimes don't
require the "@Injectable()" decorator
(e.g. https://stackblitz.com/edit/angular-hpo7gw)

With Ivy, provider classes need to be explicitly decorated with
the "@Injectable()" decorator if they are declared as providers
of a given module. This commit introduces a migration schematic
which automatically adds the explicit decorator to places where
the decorator is currently missing.

The migration logic is designed in a CLI devkit and TSlint agnostic
way so that we can also have this migration run as part of a public
CLI migration w/ `ng update`. This will be handled as part of a follow-up to reiterate on console output etc.

Resolves FW-1371

PR Close #30956
2019-07-23 15:52:40 -07:00
crisbeto c0955975f4 feat(core): add automatic migration from Renderer to Renderer2 (#30936)
Adds a schematic and tslint rule that automatically migrate the consumer from `Renderer` to `Renderer2`. Supports:
* Renaming imports.
* Renaming property and method argument types.
* Casting to `Renderer`.
* Mapping all of the methods from the `Renderer` to `Renderer2`.

Note that some of the `Renderer` methods don't map cleanly between renderers. In these cases the migration adds a helper function at the bottom of the file which ensures that we generate valid code with the same return value as before. E.g. here's what the migration for `createText` looks like.

Before:
```
class SomeComponent {
  createAndAddText() {
    const node = this._renderer.createText(this._element.nativeElement, 'hello');
    node.textContent += ' world';
  }
}
```

After:
```
class SomeComponent {
  createAndAddText() {
    const node = __rendererCreateTextHelper(this._renderer, this._element.nativeElement, 'hello');
    node.textContent += ' world';
  }
}

function __rendererCreateTextHelper(renderer: any, parent: any, value: any) {
  const node = renderer.createText(value);
  if (parent) {
    renderer.appendChild(parent, node);
  }
  return node;
}
```

This PR resolves FW-1344.

PR Close #30936
2019-07-03 09:03:37 -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