TypeScript error

[RossComputerGuy]

node_modules/pony-cause/index.d.ts:5:5 - error TS2416: Property 'cause' in type 'ErrorWithCause<T>' is not assignable to the same property in base type 'Error'.
  Type 'T' is not assignable to type 'Error | undefined'.
    Type 'T' is not assignable to type 'Error'.

5     cause: T;
      ~~~~~


Found 1 error in node_modules/pony-cause/index.d.ts:

[floriankrueger]

We're running into the same issue. Any plans to look into this?

[benasher44]

Updating the constraint for the Error generic parameter for cause like this fixes it:

ErrorWithCause<T extends Error | undefined = undefined>

[RossComputerGuy]

https://github.com/CerusBots/api/blob/master/patches/pony-cause%2B1.1.1.patch I made this patch using patch-package and it works but @benasher44's fix doesn't work sing umzug is unhappy then

[benasher44]

We did the same and just patched unzug as well to pass Error instead of unknown cc @mmkal

[voxpelli]

Relates to microsoft/TypeScript#48098, and as @ljharb said in DefinitelyTyped/DefinitelyTyped#59354 (comment):

the bug is in the base error cause types

And microsoft/TypeScript#45167 (comment) is still open for this very reason.

I note that there's also another incorrect Error related type in TS, that the type of .stack while being optional is not explicitly allowed to be undefined: microsoft/TypeScript#45748

So: We have to fix this in TS.

In the meanwhile: You can downgrade to an older version of TS, like eg. TS 4.5, to avoid this error.

[voxpelli]

Would by the way love a PR with a test case that reproduces this, so that we can more easily verify that its working again 👍

[voxpelli]

Doing some more pinning down on when this was introduced:

1. This is caused by "lib": ["es2022"] or more specifically the es2022.error lib. esnext will include es2022 on TS 4.6 and later.
2. No es2022 stuff is documented in the online lib documentation, but in the TS 4.6.4 CLI it is documented:

   Argument for '--lib' option must be: 'es5', 'es6', 'es2015', 'es7', 'es2016', 'es2017', 'es2018', 'es2019', 'es2020', 'es2021', 'es2022', 'esnext', 'dom', 'dom.iterable', 'webworker', 'webworker.importscripts', 'webworker.iterable', 'scripthost', 'es2015.core', 'es2015.collection', 'es2015.generator', 'es2015.iterable', 'es2015.promise', 'es2015.proxy', 'es2015.reflect', 'es2015.symbol', 'es2015.symbol.wellknown', 'es2016.array.include', 'es2017.object', 'es2017.sharedmemory', 'es2017.string', 'es2017.intl', 'es2017.typedarrays', 'es2018.asyncgenerator', 'es2018.asynciterable', 'es2018.intl', 'es2018.promise', 'es2018.regexp', 'es2019.array', 'es2019.object', 'es2019.string', 'es2019.symbol', 'es2020.bigint', 'es2020.promise', 'es2020.sharedmemory', 'es2020.string', 'es2020.symbol.wellknown', 'es2020.intl', 'es2021.promise', 'es2021.string', 'es2021.weakref', 'es2021.intl', 'es2022.array', 'es2022.error', 'es2022.object', 'es2022.string', 'esnext.array', 'esnext.symbol', 'esnext.asynciterable', 'esnext.intl', 'esnext.bigint', 'esnext.string', 'esnext.promise', 'esnext.weakref'.
   The online lib documentation do state the very true:
   This list may be out of date

3. lib will default to the value of target, so if target is es2022 or esnext on TS 4.6 or later then it will include the troublesome new Error definition. And the online target documentation does indeed document es2022

So, conclusion: You can also avoid this issue by setting lib implicitly through target or explicitly to something that doesn't include es2022.error

[voxpelli]

I have now merged #36 which added tests that reproduces this very fact.

[voxpelli]

There is now a PR to TS by @iamharbie that fixes this: microsoft/TypeScript#49639

Lets hope it get merged and released soon

[voxpelli]

The mentioned PR has now been merged into TS: microsoft/TypeScript#49639

Not sure in what release it's going to appear. I hope it's going to be in at least TS 4.8