Migrate from dtslint to tsd

[arnfaldur]

This tracks the work spoken about in this issue #1985

It is not ready yet but I decided to make it a draft PR here so anyone could look at and comment on the changes if they wanted to.

I ran prettier on all the files to be changed so there are some non-functional changes but they will in almost all cases be overridden by functional changes.

I don't expect to change much of the code that has had a functional change on my volition, in case of suggestions, I will of course do so.

[arnfaldur]

The migration is done and all tests pass.

tsd is not very configurable and needs the dist/immutable.d.ts file to exist when run so I added a quick fix for that. b0ae165
That is what was causing the CI breakage earlier.

There were three troublesome tests marked FIXME in the code
https://github.com/arnfaldur/immutable-js/blob/5959be5b424e5aa11c41e2f4c61a9d7fdc8f35c8/type-definitions/ts-tests/map.ts#L95
https://github.com/arnfaldur/immutable-js/blob/5959be5b424e5aa11c41e2f4c61a9d7fdc8f35c8/type-definitions/ts-tests/map.ts#L98
These two are both cases of getIn returning never instead of number as dtslint expected them to do. Like this:

  expectType<never>(Map({ a: 4, b: true }).getIn(['a']));

I don't know how important it is so I just changed it to never but let me know if it's something to look into.

The last one is an expected error while doing this:

Map({ a: 1, b: 'b' }).update(v => ({ a: 'a' }))

By the context it seems to be trying to assign a string to a number but that is tested a few lines down and the failure case is just that it's updating with a regular JS object instead of Immutable.Map or similar.
I just commented it out but have submitted a pull request to tsd to enable the error and the test can be re-enabled then.

[mrazauskas]

Seems to be specified in ./type-definitions/ts-tests/tsconfig.json:

immutable-js/type-definitions/ts-tests/tsconfig.json

Lines 13 to 15 in ac05955

	"paths": {
	"immutable": ["../../type-definitions/immutable.d.ts"]
	}

[arnfaldur]

Indeed it is. I was unable to make tsd read that tsconfig.json file but did not put much time into it. If you know how, please share.

[mrazauskas]

Hard to say. Might be worth opening an issue in their repo.

Some time ago I was maintaining a forked tsd-lite. All I remember is that the original config logic was rather some spaghetti code. It was fully replaced in the fork.

[mrazauskas]

Just to draw attention, here you are hitting one of tsds oddities. Both of the following tests are passing:

expectAssignable<Map<number, number>>(Map());
expectNotAssignable<Map<number, number>>(Map());

[mrazauskas]

Just above there is this test:

expectType<Map<unknown, unknown>>(Map())

If the inferred type of Map() is Map<unknown, unknown>, it cannot be assigned to Map<number, number>.

To make it assignable, the type has to be cast to Map<number, number> first. This is what expectAssignable() does, but expectNotAssignable() does not. In my opinion expectNotAssignable() behaves correctly.

[jdeniau]

Superseeded by #1991.

Thank you @arnfaldur for all the work you made here. Sorry that I did not discovered tstyche before !

[arnfaldur]

You're welcome, no need to apologize. It's good to see the issue resolved nicely. Thanks for seeing it through @mrazauskas 🙌