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.

[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

[utkarshkukreti]

For anyone interested, here's the updated resolutions workaround I'm using for latest typescript and jest.

I'm using it in a new project and everything seems to be working fine; I'll update if anything breaks.

  "resolutions": {
    "**/@typescript-eslint/eslint-plugin": "^4.11.1",
    "**/@typescript-eslint/parser": "^4.11.1",
    "**/jest": "^26.6.3",
    "**/ts-jest": "^26.4.4",
    "**/typescript": "^4.1.3"
  }

[stephenh]

We're prototyping a new project on tsdx and after an ~hour of fighting "why does jsxImportSource" not work (for emotion setup), it turns out tsdx was using its own shadowed version of TypeScript. Pretty frustrating. Personally I'm close to moving off tsdx, but for now we can switch from npm to yarn and use the ^ resolutions.

All of the projects in our company are on TS 4.x and prettier 2.x, so kinda surprised to see tsdx behind on these.

Granted, it's open source / it's free / etc. :-), so I'm looking forward to liking/using tsdx going forward, but just reporting back today's frustrations from the field.

[TheBit]

@stephenh I also looked to this lib, but it has phantom dependencies all over the place and thus is incompatible out-of-the-box with Rush with pnpm. I tried to fix this myself, but when it took more then several days with no luck - I quit.

[rhyek]

In case anyone is using pnpm >= 5.10.1 you can use overrides (https://pnpm.io/package_json#pnpmoverrides):

  "pnpm": {
    "overrides": {
      "typescript": "^4.3.0"
    }
  }

[aladdin-add]

just released a fork @weiran.zsd/tsdx, the main changes are:

• drop node.js <12
• upgrade eslint v7
• upgrade typescript v4
• upgrade jest v27

[doasync]

I have used resolutions workaround #926 (comment) with updated versions and it worked too:

  "resolutions": {
    "**/@typescript-eslint/eslint-plugin": "^5.4.0",
    "**/@typescript-eslint/parser": "^5.4.0",
    "**/jest": "^27.3.1",
    "**/ts-jest": "^27.0.7",
    "**/typescript": "^4.4.4"
  }

[Ricardo-Marques]

The resolutions suggestions above did not fix my issue, which was a build error being thrown by babel anywhere that I attempted to leverage typescript template literals.

What ended up fixing that issue was upgrading @babel/core

yarn add --dev @babel/core@latest @typescript-eslint/eslint-plugin@latest @typescript-eslint/parser@latest

  "resolutions": {
    "**/typescript": "^4.6.2",
    "**/@typescript-eslint/eslint-plugin": "^5.16.0",
    "**/@typescript-eslint/parser": "^5.16.0",
    "**/@babel/core": "^7.12.3"
  }

[0xalecks]

To add on the previous comments, yarn 3 does not support glob patterns in resolutions (**/). This fixed the issue for me:

"resolutions": {
    "typescript": "4.8.4"
  },