For abstract types you should cast to Type<MyAbstract>

couldn't get<T>(token: T | InjectionToken<T>, notFoundValue?: T, flags?: InjectFlags): any; be enough?

No because MyClass as an argument is type typeof MyClass

For example: if you were using Injector.get to get ChangeDetectorRef, you'd get the same warning because ChangeDetectorRef is an abstract class and you'd need to cast to Type<ChangeDetectorRef>.

The change in TestBed.get was to make the function signature slightly similar to Injector.get, but having it return any for now, My plan is to send a PR for review where TestBed.get<T> would return a type T instead of any.

More info on Issue #26491

@Goodwine Thank you for your answer. Yeah I knew this was the goal and I very much look forward to it ;)

My point is:

• can we have a better signature to not have to explicitely cast to Type<MyAbstract>? (looks like no?)
• if no, maybe the deprecation message and the changelog message should be more explicit about this use-case. Injector.get is not used that often in an application, whereas TestBed.get is used in pretty much every service unit test. So the deprecation message is showing up a lot after upgrading and other developers are going to wonder if this is normal or not.

It would be awesome to not have to cast, because I think it's not a very good developer experience to have to write:

import { Type } from '@angular/core';

const http = TestBed.get(HttpTestingController as Type<HttpTestingController>);

I realize the new signature has another issue. I had many warnings with abstract classes but I also had others that looked weird and I figured it out.

If you have a strict TS config, more specifically if you have strictFunctionTypes turned on (which is the case if you activate the strict option), the deprecation warning shows up even for a simple case:

@Injectable({
  providedIn: 'root'
})
export class UserService {

  constructor(private http: HttpClient) {}

}

const service: UserService = TestBed.get(UserService); // tslint is unhappy

I guess this is because the Type signature in core.d.ts is:

export declare const Type: FunctionConstructor;

export declare interface Type<T> extends Function {
    new (...args: any[]): T;
}

(which is OK for bivariance check but not for contravariance check like strictFunctionCheck does).

This is going to be confusing for developers that activated the strict option in their TS config.

Re: better type for abstract class
Yes, there will be a better signature for get where you don't have to cast the abstract class

Re: strictFunctionCheck
Let me ask a coworker

@cexbrayat I tried reproducing the issue and couldn't, I guess that's because the error comes from a tslint check and not from the compiler strict option, what rule is the one failing?
I looked at https://palantir.github.io/tslint/rules/ and the only one that looked similar was strict-type-predicates, is that the one that failed for you? Or do you have your own strictFunctionCheck tslint rule?

repro attempt: (in options enable strictFunctionTypes) playground

@Goodwine Sorry if I wasn't clear.

The TS rule failing is still the deprecated one.
Because when strict or strictFunctionCheck option is enabled, TestBed.get doesn't match the new signature but the deprecated one.

See repo for a reproduction: https://github.com/cexbrayat/test-bed-get

Or you can manually reproduce with:

ng new test-bed-get --defaults // using CLI 8.0.0-beta.15
cd test-bed-get
ng g s user

Replace user.service.ts by:

import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';

@Injectable({
  providedIn: 'root'
})
export class UserService {

  constructor(private http: HttpClient) {}
}

Change the tsconfig.json file to have the strict option enabled:

{
  "compileOnSave": false,
  "compilerOptions": {
    "baseUrl": "./",
    "outDir": "./dist/out-tsc",
    "sourceMap": true,
    "declaration": false,
    "module": "esnext",
    "moduleResolution": "node",
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "strict": true,
    "importHelpers": true,
    "target": "es2015",
    "typeRoots": [
      "node_modules/@types"
    ],
    "lib": [
      "es2018",
      "dom"
    ]
  }
}

Then run ng lint, you should get:

WARNING: test-bed-get/src/app/user.service.spec.ts:9:42 - get is deprecated: from v8.0.0 use Type<T> or InjectionToken<T>

Thanks for the detailed repro steps, I'll take a look tomorrow and will try to come up with a PR to fix this issue.

This is - microsoft/TypeScript#24428

I'll see whether I can update Type<T> as suggested over there

After talking to the team it was decided to temporarily remove the @deprecated annotation to avoid too much noise in v8, until we properly fix it. See #30514

Thanks, can you look at my 2 PRs that would fix this?

@Goodwine I pinged the team about that, and someone that knows more than me will review (but v8 is keeping everyone pretty busy so we decided to remove the deprecation annotation as a first easy fix). 👍 Thanks for your help @Goodwine

Closed by 561e01d

@kara I think we should keep this open until we properly fix it. The commit removing the @depecated tag was just a quick fix to avoid too much noise in v8 and only partially address the issue.

For example the new signature still forces us to write:

import { Type } from '@angular/core';

const http = TestBed.get(HttpTestingController as Type<HttpTestingController>);

which is not ideal.

How did this get overlooked on the upgrade guides and breaking changes? Unit tests are not second class code. I'm seeing this in the latest release version 8.0.0. Are we awaiting a quick bug-fix release that will allow this to work? Or for 8.0.0 do I just have to use the new get<T>?

@jkyoutsey this wasn't meant to be a breaking change, but due to a TSLint bug it ended up being one. @angular/core@8.0.2 should resolve this temporarily.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}