Tsdx: Support Typescript 4

[vberlier]

Current Behavior

Creating a new project with the example code from the official release notes doesn't work:

type Arr = readonly any[];

export function concat<T extends Arr, U extends Arr>(arr1: T, arr2: U): [...T, ...U] {
  return [...arr1, ...arr2];
}

$ yarn build
semantic error TS1256: A rest element must be last in a tuple type.

$ yarn lint
Parsing error: Cannot read property 'map' of undefined

Workaround

For the moment I managed to work around it by updating typescript and typescript-eslint and forcing the resolutions:

$ yarn add --dev typescript@latest @typescript-eslint/eslint-plugin@latest @typescript-eslint/parser@latest

// package.json

"resolutions": {
  "**/typescript": "^4.0.5",
  "**/@typescript-eslint/eslint-plugin": "^4.6.1",
  "**/@typescript-eslint/parser": "^4.6.1"
}

[agilgur5]

Hmm.. So the linting portion duplicates #810 which just recently got unblocked by a new release of eslint-config-react-app upstream.

But oddly enough #810 doesn't report issues with any TS syntax. Perhaps there's a subset that's compatible but some of it isn't, per the TS release notes.

TSDX normally uses whatever version of TS is available in node_modules, which has allowed users to use newer versions of TS before TSDX upgraded to them. But I think since all versions were TS v3 previously, it would just get deduplicated / flattened in node_modules as a single TS version.
Since TS v4 released as a major (notably, TS doesn't follow SemVer as each minor has breaking changes in it too), I'm guessing this made two versions of TS appear in the node_modules tree and so TSDX ended up using the v3 which matches its internal version.
I actually wasn't sure exactly how this behavior would play out, so thanks for showing an example.

To respond to the request though, a breaking upgrade to TS v4, ESLint v7, Prettier v2, etc etc (one dep upgrade requires another dep upgrade requires another etc 😕 ) is already scheduled for v0.16.0. Because this dep upgade it's so breaking, I've planned it to occur when there are no other breaking changes occurring for the least possible confusion and to space out planned/required breakage.

Also thanks for providing the workaround with resolutions and confirming that it works.

[JustFly1984]

Is there any movement on supporting TS4 ? Users of my library requesting react 17 support, and I can't build new version.
Thank you!

[agilgur5]

@JustFly1984 please read the comments. This is already scheduled for v0.16.0, is very breaking and requires updates of several deps (one of which only recently updated), and has workarounds available...

I'm not sure what you mean by you can't build a new version... this is not a blocker as it has a workaround, and current TSDX can build.

[viniciusflv]

In addition to the TS4 support, i'd like to say that the new TS4.1 template string types are not working properly. I'm not capable of saing the extension of the problem, but it would be really cool if you could also target this issue.
I Love this lib S2!

[agilgur5]

@viniciusflv if the resolutions workaround above doesn't work for you for template strings, then that would likely be a bug upstream in rollup-plugin-typescript2. But the workaround should work.
Template string types are a new syntax/feature so they're not backward compatible with older TS versions. But yes, I'm planning to upgrade to whatever the newest and fully ecosystem supported (e.g. eslint and prettier need to support new ASTs and rules with new versions, so it's not immediate) TS version is when v0.16.0 is released. Also you'll be able to bring your own version of TS 4.x once TSDX upgrades to it as one could with 3.x per my initial comment