Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor(core): various fixes for missing-injectable migration #33286

Commits on Oct 24, 2019

  1. fix(core): missing-injectable migration should handle forwardRef

    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.
    devversion committed Oct 24, 2019
    Copy the full SHA
    c906547 View commit details
    Browse the repository at this point in the history
  2. fix(core): missing-injectable migration should not migrate providers …

    …with "useExisting"
    
    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.
    devversion committed Oct 24, 2019
    Copy the full SHA
    be842da View commit details
    Browse the repository at this point in the history
  3. fix(core): missing-injectable migration should not update type defini…

    …tions
    
    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.
    devversion committed Oct 24, 2019
    Copy the full SHA
    4656cae View commit details
    Browse the repository at this point in the history