如何键入JavaScript代码使用的TypeScript库中公开的函数的参数？

Question

I am creating a library written in Typescript which expose a class with a constructor that accept one parameter of type Set .

This library will be used by a application written in javascript, I need to check that the parameter is a valid Set . My code currently looks something like that:

export class Something {
  private mySet: Set<string>;

  constructor(aSet: Set<string>) {
    if (!(aSet instanceof Set)) {
      throw new TypeError('Invalid parameter');
    }

    this.mySet = aSet;
  }
}

I created a test suite that checks this code:

it('should throw if instantiate without parameter', () => {
  expect(() => {
      new Something();
  }).toThrow();
});

it('should not throw if parameter is a Set', () => {
  expect(() => {
      new Something(new Set([1, 2]));
  }).not.toThrow();
});

The Typescript compiler rightfully shown an error TS2554: Expected 1 arguments, but got 0 on the first test.

The only way I found to fix this issue is to change the constructor signature and declare my parameter as optional with type any , but it doesn't feel right...

export class Something {
  private mySet: Set<string>;

  constructor(aSet?: any) {
    if (!(aSet instanceof Set)) {
      throw new TypeError('Invalid parameter');
    }

    this.mySet = aSet;
  }
}

Is it the proper approach or is there a better way to handle this?

Answer 1

Of course, the parameter shouldn't be made optional to make tests pass, this defies the purpose of strict typing.

A function should be asserted with another type if it's not used like intended:

  expect(() => {
      new (<any>Something)();
  }).toThrow();

Or, more specifically with construct signature that throws an error, ie returns never :

  expect(() => {
      new (<{ new(): never }>Something)();
  }).toThrow();

Answer 2

Currently, I think that there are no appropriate approach for solving your problem, unless the TypeScript team have implemented disable compiler error for specific line. This feature is already mentioned here but it is still yet to come.

So by now, it's either you sacrifice type-safety or you should just ignore that error thrown by the compiler.