Closed ehmicky closed 3 months ago
I can reproduce directly with typescript
(i.e. without installing tsd
, @tsd/typescript
and skipping the import from tsd
). Bisecting points to https://github.com/microsoft/TypeScript/pull/51367 as the first bad commit. Does this make any sense?
This is interesting. When I run the above with tsc
and do not import tsd
, this does not crash for me. Also, it runs very fast, while tsd
runs for 10+ seconds before crashing.
Also, I am curious how the above TypeScript commit would have an impact on the above. It only adds type definitions for Array.with()
, Array.toSorted()
, Array.toReversed()
, Array.toSpliced()
, but the example above is not using any of them. :thinking:
Could you point to concrete types which are causing the problem, please? I always struggle to understand abstract A
, B
, C
stuff. Easier to play with tools, but not so easy to understand the intent behind these types.
Do I get it right that your provided type D
is doing something with the keys of an Array
? Hm.. Not sure why this would be needed.. If that's the case, note that the PR I was referencing is adding more keys to the Array
object. That could explain the OOM.
I would like to provide with a more meaningful example. However, the original types are quite complex. I spent several hours reducing them to the minimal example above, but it started to get nonsensical at some point.
That being said, while understanding the original intent would be helpful for a feature request, this is quite clearly a bug. Regardless of the original intent, the example above should not crash (even if the types do not make sense).
Now, I have been doing some additional research, and it appears that the problem is actually not related to tsd
but to TypeScript. What seems to happen is: since TypeScript 5, some specific combinations of extends
+ Tuples seem to create big union types internally. Sometimes, this creates the following error:
TS2590: Expression produces a union type that is too complex
Other times, it crashes with OOM. In my case, the reason it fails only when using tsd
seems to be that importing tsd
requires some memory, which makes it go beyond the memory crash threshold.
I managed to reproduce the bug with only TypeScript, without tsd
. Although it looks different, it seems to be the same underlying problem. I have opened https://github.com/microsoft/TypeScript/issues/58268 to track this. The example I used there is a little more sensical.
Thanks for looking into this! :+1:
The following crashes:
System: Ubuntu
23.10
, Node21.7.2
, latesttsd
(0.31.0
). I could also reproduce this bug on a GitHub action running on Windows, macOS and Linux. So this does not appear to be OS-related, nor machine-related. Node16.17.0
crashes too, so this does not appear to be Node version-related either.However, it does appear the above bug might be related to the
5.2.2
release of@tsd/typescript
, which was shipped withtsd@0.29.0
.At first, it might look this is not an issue with
tsd
but with TypeScript. However:tsc
on the above files does not crash. Only callingtsd
does.import 'tsd'
statement makes it not crash anymore. Even though nothing is imported/used fromtsd
.If the above types do not make much sense, that's because they are a reduction of the original types (which did make sense). Although not quite sensical, those types are quite simple and not circular, so they should not cause a memory crash. I could not reduce them any further.
This bug is currently preventing Execa from upgrading
tsd
. Namely, upgradingtsd
will make memory crash. The above is a reduction of that problem.This is a very strange bug because very minor changes fail to reproduce it. This includes:
B
instead ofA
, even thoughA
should be identical toB
, in principleextends 2
intoextends 1
, even though neither1
nor2
is used anywhere elseThe memory crash happens after
tsd
runs for 10+ seconds. That's quite slow for such small types, so it seems liketsd
is getting stuck in some loop until it crashes with OOM.