tsgo "Type instantiation is excessively deep and possibly infinite" error when using react-hook-form

[justinsmid]

My project makes heavy use of react-hook-form. A quick git grep tells me we have 310 forms.

On two of them we are getting the "Type instantiation is excessively deep and possibly infinite" error when using tsgo. We have never had this error in these places with tsc.
We don't do anything special on those two forms compared to our other forms as far as I can tell, but it does seem to be consistently on those and only those two forms.

The error occurs when rendering the FormProvider. This component expects the entire result of useForm, so you're expected to spread the whole form when using it, which I can imagine gets quite heavy during typechecking:
https://github.com/react-hook-form/react-hook-form/blob/90cdaee9ba148e6c28fe3cb69f885ae1541f7c04/src/types/form.ts#L916

// ...

const form = useForm({ ... })

return (
// v -- "Type instantiation is excessively deep and possibly infinite" error occurs here in tsgo
  <FormProvider {...form}>
    {/* ... */}
  </FormProvider
)

Unfortunately I have not been able to reproduce the issue in a standalone repository.
We also have a wrapper around their useForm to give us more accurate types, which makes fairly heavy use of generics, so I imagine that's contributing to the issue, but even with that wrapper I have not been able to reproduce it standalone.
I'm guessing it's partially related to the large amount of these forms I have in my actual repo.

I'm not sure if this is something you can work on or help me out with without a reproduction, but figured I'd try anyways.
Would be happy to provide more details on our usage if there's anything you think would be helpful, but our actual repo is private so unfortunately I cannot publicly share it fully.

(Using "@typescript/native-preview": "7.0.0-dev.20250529.1")

[ahejlsberg]

I suspect #1284 may fix this issue.

[jakebailey]

@justinsmid Even if your repo is large, is it still public and runnable? If not, can you build #1284 and see if it works?

[jakebailey]

Or, anyone else who thumbs up'd this issue? We really need some sort of repro. The next nightly will contain that PR so should be reasonable to test.

[justinsmid]

@jakebailey

Even if your repo is large, is it still public and runnable? If not, can you build #1284 and see if it works?

It is unfortunately not public no.
I'll give building that version a go and let you know!

[jakebailey]

If you wait another half hour or so, the next version will be published to npm and the VS Code Marketplace, which might be easier.

[justinsmid]

@jakebailey I built the latest master (since the PR in question was merged), and when running that against my repo I'm noticing heavily increased memory usage. It starts off normally and slowly creeps up and shows no signs of stopping, so I had to cancel it manually before it finished when it started getting to my pc's limit:

[jakebailey]

Was this in the editor, or a CLI run? I assume the latter? Unfortunately I don't really have a great method to debug such a thing, unless this is an infinite loop, in which case you could try running tsgo directly, then hit Ctrl+\ to force it to exit and print out all of its stacks.

[LukeAbby]

If you make a quick patch to cmd/tsgo/main.go you can add net/http/pprof in order to dump a heap profile.

Here's the exact patch:

pprof patch

diff --git a/cmd/tsgo/main.go b/cmd/tsgo/main.go
index 1f8ad0960..77c21cf01 100644
--- a/cmd/tsgo/main.go
+++ b/cmd/tsgo/main.go
@@ -1,12 +1,20 @@
 package main
 
 import (
+       "log"
        "os"
 
+       "net/http"
+       _ "net/http/pprof"
+
        "github.com/microsoft/typescript-go/internal/execute"
 )
 
 func main() {
+       go func() {
+               log.Println(http.ListenAndServe("localhost:6060", nil))
+       }()
+
        os.Exit(runMain())
 }

You'll want to build with debug info and optimizations disabled, that is go build -gcflags="all=-N -l".

Then you should run it and when the memory has spiked you can run go tool -top pprof http://localhost:6060/debug/pprof/heap and upload the results (it'll say the top usages as well as save a resulting file you can upload).

If the team would be interested I'd be happy to add something like this behind a flag to TS Go.

[jakebailey]

That's a good idea, though I don't know if we are going to want to integrate it into the binary because that means that our code technically has networking/crypto stuff shipped, so we'd have to do a bunch of compliance work. Not impossible, just more work.

[justinsmid]

Was this in the editor, or a CLI run? I assume the latter?

That was indeed a CLI run.

I'll give dumping the debug info a go now!

[LukeAbby]

@jakebailey I would add runtime/pprof which avoids all the HTTP server stuff. I showed off how to do the HTTP server way because it's 6 total lines of code whereas it's a bit more work for runtime/pprof.

[jakebailey]

We already have it integrated as the flag --pprofDir to dump profiles, but it only works if the process exits.