DEV Community: Ran Lottem

Extending the Array map() function

Ran Lottem — Fri, 28 Feb 2020 19:43:10 +0000

When writing TypeScript or JavaScript code, you'll come across a lot of code snippets like this:

const result_1 = myArray.map(x => doSomething(x));
const result_2 = myArray.map(x => x.property);
const result_3 = myArray.map(x => x.toString());

These lines of code are pretty similar - they produce an array from an input array. This is done by doing one of a few things on each element of the input array: calling a function with the element as the argument, accessing a property on the element, or calling one of the element's class methods. With a few funny exceptions, calling a function with the argument being the array element can be abbreviated like this:

const result_1 = myArray.map(doSomething);

If the function doSomething only takes one argument and does not reference a this object we would usually by fine using this shorter syntax. The other two examples above can't be abbreviated like that, and I'll show a [subjectively] elegant solution here.

Overloading Array.map()

Property Access

I want to be able to do the property access without that x => x.<prop> syntax. I want to achieve this:

const result_2 = myArray.map('property');
const result_2 = myArray.map('undefinedProperty'); // error here

The function and its type signature were actually the simpler part for me to implement, it's adding to the basic Array<T> type that took some trials to get to, but here's the result:

interface Array<T> {
    mapTo<K extends keyof T>(k: K): Array<T[K]>;
}

Array.prototype.mapTo = function <T, K extends keyof T>(this: T[], k: K) {
    return this.map(x => x[k]);
};

The use of the keyof keyword ensures that for an array with elements of type T we can only provide the name of one of T's properties. The x => x[k] syntax is used in the implementation, but we don't have to use it ever again. We can map as we always have, or use this overload in case we're only doing a property access.

Function Call

This one is slightly trickier, since the generic type parameter T isn't necessarily a function type. We want to be able to map from an array of functions to an array of results of those functions being called, but we can't simply go x => x(...args) for any old x of type T. To accomplish this, we'll introduce our own subtype of Array, the FunctionalArray (that is not to say ordinary arrays are dysfunctional, though ;)

class FunctionalArray<A extends any[], R> extends Array<(...args: A) => R> {
    mapToCall(...args: A): R[] {
        return this.map(x => x(...args));
        // consider the alternative:
        return this.map(function(x) { return x(...args); })
    }
}

A FunctionalArray is an Array where each element is a function, and has two type parameters - A for the function's argument types, and R for its return type. This lets us easily define mapToCall using those type parameters, and we're free to use the array elements as functions because we've defined this to be an array of functions of the appropriate types.

The next step is to use our new FunctionalArray class with our new Array<T>.mapTo so we can actually do something cool like this:

[1, 2, 3].map(x => x.toExponential()); // rewrite as:

[1, 2, 3].mapTo('toExponential').mapToCall();

To do this we can have mapTo return a FunctionalArray if it can:

interface Array<T> {
    mapTo<K extends keyof T>(k: K): T[K] extends (...args: infer A) => infer R ? FunctionalArray<A, R> : Array<T[K]>;
}

This return type means that for an array of type T where type T[K] is a function, mapTo will actually return the correct FunctionalArray with the relevant type parameters, or just an Array<T[K]> otherwise.

We can now replace mapping an array using a simple property access with mapTo and calling a method with mapTo followed by a mapToCall. An contrived example using an object literal with some method:

[{ omg(x?: number): number { return 2; } }].mapTo('omg').mapToCall(2); // optional argument can be provided
[{ omg(x?: number): number { return 2; } }].mapTo('omg').mapToCall(); // or omitted
[{ omg(x: number): number { return 2; } }].mapTo('omg').mapToCall(); // an error is produced if a required argument is not provided

Partial Function Application

I can imagine the function being called with mapToCall might require several arguments, which might not all be available at the location where the mapping is invoked. In this case we might consider providing some of the arguments and providing a FunctionalArray of curried functions. Consider this code:

type someFunctionType = (a: string, b: number, c: string, d: number) => string;

let func: someFunctionType;

// expected type: FunctionalArray<[string, number], string>
const curriedResult = ([func] as FunctionalArray<[string, number, string, number], string>).mapToCall("hello", 1);

In the above example, mapToCall was called with only the first two arguments, and returned a FunctionalArray of partially-applied functions - when called, the functions stored in curriedResult would call func with the first two arguments being fixed as 'hello' and 1.

There's A great StackOverflow answer on typing curried functions by SO user jcalz, so it seems possible to type this overload of mapToCall correctly, even if it does require manually unrolling type signatures for various numbers of function arguments. I think it goes a bit beyond the scope of this post, but I might write about it in the future.

Improve your Jest test code with Typescript ADTs

Ran Lottem — Sun, 16 Jun 2019 19:39:28 +0000

Jest is a JavaScript testing framework that's widely used in JavaScript projects. I personally use it on an Angular project written in TypeScript. It makes it easy to create mocks of services for unit tests, and the tests themselves are easy to read, understand, and extend when necessary.

When a component changes, its testing should also change to check the correctness of the new implementation. It is however possible to alter a component or an injected service without any of the tests failing or giving any warning. Some of these cases and the ways TypeScript types help minimize their occurrence are the topic of this post.

Let's use this TestService testing file as an example:

describe('TestService', () => {
    let authenticationServiceMock;
    let SUT: TestService;

    beforeEach(() => {
        const authorizationSources = ['system', 'override', 'automation'];

        authenticationServiceMock = {
            getAuthSources: jest.fn(() => authorizationSources),
            isSourceAuthorized: jest.fn((sourceCandidate: string) => authorizationSources.includes(sourceCandidate)),
            login: jest.fn((username: string, password: string) => of(username === 'admin' && password === '123')),
        };

        TestBed.configureTestingModule({
            providers: [
                { provide: AuthenticationService, useValue: authenticationServiceMock },
            ]
        });
        SUT = TestBed.get(TestService);
    });

    test('should be created', () => {
        expect(SUT).toBeTruthy();
    });

    test('can login', () => {
        const user = 'wrong';
        const pass = 'wrongpass';
        SUT.login(user, pass).subscribe(
            result => {
                expect(result).toBe(false);
            }
        );
        expect(authenticationServiceMock.login as jest.Mock).toHaveBeenCalledTimes(1);
        expect((authenticationServiceMock.login as jest.Mock).mock.calls[0][0]).toBe(user);
    });
});

Several things here could be improved to avoid spending time changing the test file with minor details each time something is changed in the tested service. It could also be made more type-safe.

The AuthenticationService mock has no type, so any changes to AuthenticationService would cause this test to continue passing when it shouldn't. It could also fail even though TestService would also change along with its dependency, but then the test would fail, again due to the outdated mock implementation of AuthenticationService
If we gave AuthenticationService a type, we would still need to cast its functions to jest.Mock to use jasmine matchers like toHaveBeenCalledTimes, or to access the jest mockInstance mock property to check the arguments in a function call.
When using the mock.calls array, it's just a any[][] type, and if we wanted to get the actual type of the parameters to the login method, we would have to cast it to the explicit and wordy mock type, like so:

  expect((authenticationServiceMock.login as jest.Mock<Observable<boolean>, [string, string]>).mock.calls[0][0]).toBe(user);

Even using this syntax, again any changes to authenticationService or to login's signature would require us to manually fix all of these casts, and it wouldn't even be that clear that the jest.Mock cast is the issue. Imagine login used to take [string, number] as input and we now refactored it to be [string, string]. We would get a very wordy error message, from which it would be hard to tell that we just need to switch the second argument's type to string.

The most basic thing we can do, is tell the compiler that our mock is of type AuthenticationService, but all of its methods are also of type jest.Mock. To do this we first need to extract all of the method names from AuthenticationService, and then create a Record type where the keys are the method names and the values are all jest.Mock:

type FunctionPropertyNames<T> = { [K in keyof T]: T[K] extends (...args: any[]) => any ? K : never }[keyof T];

This type alias uses Mapped Types and Index Types to create a type that's a union of property names from the type T. In our case FunctionPropertyNames<AuthenticationService> means exactly "login" | "getAuthSources" | "isSourceAuthorized". Our mock service type alias will therefore be:

type MockService<aService> = aService & Record<FunctionPropertyNames<aService>, jest.Mock>;

let authenticationServiceMock: MockService<AuthenticationService>;

Now we can use our mock anywhere the original service would be required (because it has the original service type), but whenever we access one of its properties, if it's a function, it will have the additional type jest.Mock. For example:

expect(authenticationServiceMock.login).toHaveBeenCalledTimes(1);
expect((authenticationServiceMock.login).mock.calls[0][0]).toBe(user);

No more awkward casting whenever we want to expect anything!

Do note that the mock object still uses the <any, any> type signature, because we did not say what the return type and parameters should be for each function. To do that we'll need to map directly over the original service type (again using Mapped Types), so we can tell each function property to be a mock of the proper type:

type BetterMockService<aService> = aService &
    { [K in keyof aService]: aService[K] extends (...args: infer A) => infer B ?
        aService[K] & jest.Mock<B, A> : aService[K] };

Now we're creating a type that has all of the same properties as aService, but for each property that's a function, it has the additional type of jest.Mock<B, A>, where B is its return type and A is a tuple of its parameters' types. We don't need to include aService in the intersection, since the new mapped type already has all of the properties of the original, but I've kept it here to show the similarity to the previous solution.

Hopefully this idea or adaptations of it can help you when typing mocks in your unit tests. Let me know of other typing tricks you use.

Getting a recursive data structure asynchronously with RxJS

Ran Lottem — Fri, 19 Apr 2019 11:28:17 +0000

In your app, you might want to save a recursive data structure - such as a folder tree. These folders could be identified by an id attribute, and contain an array of their sub-folders:

export interface Folder {
  id: number;
  name: string;
  children: Folder[];
}

However, on the server the data for each folder might only contain the identifiers for the sub-folders:

export interface ServerData {
  id: number;
  name: string;
  children: number[];
}

This means that when we write a function to return an observable of a folder, given its id, we'll first need to also get all of its sub-folders from the server before we can return the complete object.

Let's look at some mock data, and a function that gets this mock data asynchronously:

export const results: ServerData[] = [
  { id: 0, name: "first", children: [1, 2, 3] },
  { id: 1, name: "second", children: [4] },
  { id: 2, name: "third", children: [] },
  { id: 3, name: "fourth", children: [] },
  { id: 4, name: "fifth", children: [] }
];

export function getFromServer(id: number): Observable<ServerData> {
  return of(results[id]);
}

Now, let's try to transform the ServerData we get into a Folder, including its children attribute:

export function getRecursive(id: number): Observable<Folder> {
  return getFromServer(id).pipe(
    map(data => ({
      id: data.id,
      name: data.name,
      // oops, wrong type!
      children: data.children.map(childId => getRecursive(childId))
    }))
  );
}

This implementation doesn't work, because the children attribute above is actually an Observable<Folder> array. We need to combine the result from getting the parent folder with all of the results of the recursive calls to the ids of the parent's sub-folders.

export function getRecursive(id: number): Observable<Folder> {
  return getFromServer(id).pipe(
    map(data => ({
      parent: { name: data.name, id: data.id, children: [] },
      childIds: data.children
    })),
    flatMap(parentWithChildIds => forkJoin([
      of(parentWithChildIds.parent),
      ...parentWithChildIds.childIds.map(childId => getRecursive(childId))
    ])),
    tap(([parent, ...children]) => parent.children = children),
    map(([parent,]) => parent)
  );
}

What we do here is create parent without any children, and move it and its child ids further along the pipe. Then, we create an array of observables, containing the parent we already have (that's the of part) and all of the getRecursive calls for each of the sub-folder ids. Once we have the return values from each of those recursive calls, we set parent.children = children, and use array destructuring to return just the parent folder, which now has its children attribute set correctly.

A short test to show this function in action:

describe('test recursive observables', () => {
  test('test', () => {
    getRecursive(0).subscribe(data => {
      console.log(data);
      console.log(data.children.find(f => f.id === 1).children);
    });
  })
})

And the output:

    parent folder: { name: 'first',
      id: 0,
      children:
       [ { name: 'second', id: 1, children: [Array] },
         { name: 'third', id: 2, children: [] },
         { name: 'fourth', id: 3, children: [] } ] }

    children of child with id 1: [ { name: 'fifth', id: 4, children: [] } ]

Generic type guard in Typescript

Ran Lottem — Sun, 07 Apr 2019 17:59:26 +0000

Writing a generic type guard in Typescript, and what I learned from it

Introduction
Introducing the Constructor type signature
Extending the type guard to work for primitive types
Putting it all together
In summary
Sources
Addendum

Introduction

I recently had a problem at work which stemmed from a function assuming its input is of one type, while in fact it sometimes could be of a different type.

My initial attempt to fix the problem was to determine what types the input could have, and to fix the function declaration so that the input's type is the union of all possible types, and to then use type guards within the function. Something like taking this function:

export function myFunc(a: TypeA[]): void {
  // ...
}

and refactoring it into:

export function myFunc(a: TypeA[] | TypeB[]): void {
  if (a.every(e => e instanceof TypeA)) {
    // ...
  } else {
    // ...
  }
}

This made me want to write a generic version of a type guard. Then using it in an array would be as simple as:
a instanceof Array && a.every(typeGuard<T>).
But what is this typeGuard<T>? Well, I already wrote a type guard for some TypeA in the example above, so a generic type guard could simply wrap a call to instanceof. We will see a less trivial implementation later. For now, we have:

export function typeGuard<T>(o: any): o is T {
  return o instanceof T;
}

This gives us an error, however: 'T' only refers to a type, but is being used as a value here.
The issue here is that the type T is not always available at runtime, since it could be an interface - a construct that is not accessible to the underlying JavaScript. This means that writing a generic type guard to discern between interfaces wouldn't have worked - though one could write non-generic type guards for specific interfaces. This does work for classes, however:

class myClass {}

function classTypeGuard(object: any): boolean {
  return object instanceof myClass;
}

Even if we weren't trying to be generic over T, we would get the same error - the bit of code e instanceof TypeA above gives the same error about TypeA only referring to a type.

How, then, can we pass the function the type we want to check object is an instance of? For a class like myClass above, we would want to pass myClass itself to the function, like so:

function typeGuard(o, className) {
  return o instanceof className;
}
const myClassObject = new myClass();
typeGuard(myClassObject, myClass); // returns true

Introducing the Constructor type signature

The above works, but we haven't specified any type restrictions on the className variable. A line like typeGuard(myClassObject, 5) raises no errors, but would cause a runtime TypeError: Right-hand side of 'instanceof' is not an object. We need to add a restriction on className's type such that only objects that can be on the right side of instanceof can be used. This restriction stems from the definition of instanceof in JavaScript, where the object needs to be a constructor for some type. We can do this by specifying className's type like so:

type Constructor<T> = { new (...args: any[]): T };
function typeGuard<T>(o, className: Constructor<T>): o is T {
  return o instanceof className;
}
const myClassObject = new myClass();
typeGuard(myClassObject, myClass); // returns true
typeGuard(myClassObject, 5); // Argument of type '5' is not assignable to parameter of type 'Constructor<{}>'

Let's unpack some of what we see here: we declare a new type - Constructor<T> is a type that has a method new that takes any number of arguments (including zero) and returns an instance of type T. This is exactly the restriction we need to be able to use className with instanceof.

Extending the type guard to work for primitive types

So far, all we've really done is wrap instanceof with another function, albeit with fancy-looking typing. We'd also like to be able to do something like this:

typeGuard(5, 'number'); // true
typeGuard('abc', 'number'); // false

What we need to do here is widen the type of the myClass parameter we're using, to something like this: type PrimitiveOrConstructor<T> = Constructor<T> | 'string' | 'number' | 'boolean'.

Let's try and use this new type:

type PrimitiveOrConstructor<T> =
  | Constructor<T>
  | 'string'
  | 'number'
  | 'boolean';

function typeGuard<T>(o, className: PrimitiveOrConstructor<T>): o is T {
  if (typeof className === 'string') {
    return typeof o === className;
  }
  return o instanceof className;
}

class A {
  a: string = 'a';
}

class B extends A {
  b: number = 3;
}

console.log(typeGuard(5, 'number'), 'is true');
console.log(typeGuard(5, 'string'), 'is false');

console.log(typeGuard(new A(), A), 'is true');
console.log(typeGuard(new A(), B), 'is false');

console.log(typeGuard(new B(), A), 'is true');
console.log(typeGuard(new B(), B), 'is true');

console.log(typeGuard(new B(), 'string'), 'is false');

Let's examine the new implementation of typeGuard: className is now either a Constructor<T> or it's a string whose value is limited to one of 'string', 'number', or 'boolean'. In case it's a string (technically, if its type is 'string' | 'number' | 'boolean'), then typeof className === 'string' will be true, and then the type guard will be based on typeof rather than instanceof. Notice that the if checks className's type ('function' in the case of a Constructor<T> vs. 'string' in the rest of the cases), and the type guard itself is comparing type of the object we want to guard, with the actual value of className.

Something is still amiss, though. The return type for typeGuard is wrong in the case where we're checking if an object has a primitive type. Notice that typeGuard's return type is o is T. this T comes from Constructor<T> if that's className's type, but if it isn't then T is resolved as {}, meaning that for primitive types, our type guard is wrong:

function typeDependent(o: any) {
  if (typeGuard(o, 'number')) {
    console.log(o + 5); // Error: Operator '+' cannot be applied to types '{}' and '5'
  }
}

We could correct this by letting the compiler know what T is manually, like so:

function typeDependent(o: any) {
  if (typeGuard<number>(o, 'number')) {
    console.log(o + 5); // o is number, no error
  }
}

But we'd like for typeGuard's return type to be inferred from the value of className. We need to use the type PrimitiveOrConstructor<T> to guard T | string | number | boolean. First, the type T should be inferred only if the type we're guarding isn't a primitive. We will make a new PrimitiveOrConstructor which is not generic, and then use that type to infer what type it is guarding.

type PrimitiveOrConstructor =
  | { new (...args: any[]): any }
  | 'string'
  | 'number'
  | 'boolean';

The type of object PrimitiveOrConstructor creates in the non-primitive case is not specified, because it can be inferred when resolving what type is being guarded by it:

type GuardedType<T extends PrimitiveOrConstructor> = T extends { new(...args: any[]): infer U; } ? U : T;

Now, if the type we want to have a type guard for is aClass, then GuardedType<aClass> resolves to aClass. Otherwise, if we set T as 'string' then GuardedType<'string'> is just 'string' again, instead of the type string. We still need to be able to map from a string value like 'string' to the appropriate type, and to do this we will introduce keyof, and index types. First, we'll create a mapping from strings to types with a type map:

interface typeMap { // can also be a type
  string: string;
  number: number;
  boolean: boolean;
}

Now, we can use keyof typeMap to introduce the 'string' | 'number' | 'boolean' in our PrimitiveOrConstructor, and index into typeMap to get the appropriate type for GuardedType in the primitive case:

type PrimitiveOrConstructor =
  | { new (...args: any[]): any }
  | keyof typeMap;

type GuardedType<T extends PrimitiveOrConstructor> = T extends { new(...args: any[]): infer U; } ? U : T extends keyof typeMap ? typeMap[T] : never;

A few things to note here:

keyof is a keyword that takes a type and returns a union of the names of properties of that type. In our case keyof typeMap is exactly what we need: 'string' | 'number' | 'boolean'. This is why the names of typeMap's properties are the same as their types (i.e the string property has type string, and likewise for number and boolean).
GuardedType<T> now uses nested ternary ifs: we first check if the type we're guarding has a constructor (T is the type we're given that provides the constructor, U is the type actually created by that constructor - they could be the same), then we check if T is one of the primitive types, in which case we use it to index into our typeMap and go from 'string' to string.
If both of these conditions fail, the type never is used in the last branch because we will never get to it.
It would have been simpler to avoid the second if altogether and do this:

  type GuardedType<T extends PrimitiveOrConstructor> = T extends { new(...args: any[]): infer U; } ? U : typeMap[T];

But we get this error: Type 'T' cannot be used to index type 'typeMap'. In the case where T is not a constructor type, the compiler still doesn't narrow T down to keyof typeMap, and so tells us that we cannot safely use T as an index of typeMap. We will see this problem again later, it's an open issue that I feel is worth mentioning. I'll expand on it in an addendum.

Now that we've properly defined GuardedType for a given T extends PrimitiveOrConstructor, we can go back to our implementation of typeGuard:

function typeGuard<T extends PrimitiveOrConstructor>(o, className: T):
  o is GuardedType<T> {
    if (typeof className === 'string') {
    return typeof o === className;
  }
  return o instanceof className;
}

Our className parameter is now of type T extends PrimitiveOrConstructor, so GuardedType<T> resolves into the actual type we want to guard for - a class or a primitive type. We're still not done, though, because we get an error on that last line:

return o instanceof className; // The right-hand side of an 'instanceof' expression must be of type 'any' or of a type assignable to the 'Function' interface type.

The issue here is similar to what happened when defining GuardedType. Here, className's type is T extends PrimitiveOrConstructor throughout the function body, even though we would like it to narrow to 'string' | 'number' | 'boolean' inside the if clause, and to new (...args: any[]) => any after it. Instead what we have to do is assign className to a local variable with type PrimitiveOrConstructor, and use that variable because its type will be narrowed by the compiler:

function typeGuard<T extends PrimitiveOrConstructor>(o, className: T):
  o is GuardedType<T> {
    // to allow for type narrowing, and therefore type guarding:
    const localPrimitiveOrConstructor: PrimitiveOrConstructor = className;
    if (typeof localPrimitiveOrConstructor === 'string') {
    return typeof o === localPrimitiveOrConstructor;
  }
  return o instanceof localPrimitiveOrConstructor;
}

Putting it all together

Whew, that seemed like a lot to get through. Let's put it all together so we can discern the bigger picture:

interface typeMap { // for mapping from strings to types
  string: string;
  number: number;
  boolean: boolean;
}

type PrimitiveOrConstructor = // 'string' | 'number' | 'boolean' | constructor
  | { new (...args: any[]): any }
  | keyof typeMap;

// infer the guarded type from a specific case of PrimitiveOrConstructor
type GuardedType<T extends PrimitiveOrConstructor> = T extends { new(...args: any[]): infer U; } ? U : T extends keyof typeMap ? typeMap[T] : never;

// finally, guard ALL the types!
function typeGuard<T extends PrimitiveOrConstructor>(o, className: T):
  o is GuardedType<T> {
    const localPrimitiveOrConstructor: PrimitiveOrConstructor = className;
    if (typeof localPrimitiveOrConstructor === 'string') {
    return typeof o === localPrimitiveOrConstructor;
  }
  return o instanceof localPrimitiveOrConstructor;
}

And to test it out, let's use the same examples as before, only now the type guarding will actually work and give us string, number, A or B as appropriate:

class A {
  a: string = 'a';
}

class B extends A {
  b: number = 5;
}

console.log(typeGuard(5, 'number'), 'true'); // typeGuard<"number">(o: any, className: "number"): o is number
console.log(typeGuard(5, 'string'), 'false'); // typeGuard<"string">(o: any, className: "string"): o is string

console.log(typeGuard(new A(), A), 'true'); // typeGuard<typeof A>(o: any, className: typeof A): o is A
console.log(typeGuard(new B(), A), 'true');

console.log(typeGuard(new A(), B), 'false'); // typeGuard<typeof B>(o: any, className: typeof B): o is B
console.log(typeGuard(new B(), B), 'true');

console.log(typeGuard(new B(), 'string'), 'false');

In summary

Having gone through all of the above, I realize that it would almost always be simpler to test for particular cases with instanceof, for interfaces with user-defined type guards, and for primitives with typeof.

I did learn a lot from trying to solve this problem myself, and especially from a StackOverflow answer by user jcalz. This article is mostly going through their answer and explaining the different parts of it. Going through the steps of this implementation involves understanding typescript's typing system, generics, type guards, useful keywords like keyof and infer, union types, and index types.

Sources

StackOverflow answer about trying to call instanceof on a generic type

Referencing the constructor of a type in typeScript (generically)

Addendum

When we used T extends PrimitiveOrConstructor in both GuardedType and typeGuard, we saw that conditions about T's type (e.g extending a constructor vs. extending keyof typeMap) didn't help the compiler narrow down T's type, even though we defined PrimitiveOrConstructor to either be a constructor type or a valid property name of typeMap.

In the definition of GuardedType the else branch of checking for the case of a constructor type didn't let us index into typeMap, despite that being the only other option for T. In the implementation of the typeGuard function we tried to do the same in reverse order - we checked for typeof className === 'string' which covers the case of T extends keyof typeMap, but outside this clause T was not narrowed down to a constructor type.

For defining GuardedType, we had to explicitly write a second ternary if to let the compiler know that T extends keyof typeMap so we could resolve the type as typeMap[T]. For implementing typeGuard, we needed to assign className (with type T extends PrimitiveOrConstructor) to a local variable with type PrimitiveOrConstructor. This variable's type narrowed as necessary to 'string' | 'number' | 'boolean' inside the if clause, and to new (...args: any[]) => any after it.

The problem in both cases is that T is a generic type which extends the union type PrimitiveOrConstructor. As of now (2019-04-07) this is an open issue. This is luckily also mentioned in jcalz's StackOverflow answer.