Codesandbox still doesn't allow me to install the latest version

you can provide an old version as well.

Codesandbox still doesn't allow me to install the latest version

you can provide an old version as well.

The bug was introduced in 7.16.2 for me, I can only install up until 7.15.3 in CSB

The bug was introduced in 7.16.2 for me, I can only install up until 7.15.3 in CSB

You can provide the same code with an old version in a codesanbox. I need the code so i can reproduce.

The bug was introduced in 7.16.2 for me, I can only install up until 7.15.3 in CSB

You can provide the same code with an old version in a codesanbox. I need the code so i can reproduce.

Sorry but I don't succeed in getting a reproducible scenario with a small codebase.
It's something that pops up in large codebases, see TS issue on it: #6679 (comment)

then I am afraid it would be very difficult for me to investigate if I don't have a codesanbox to reproduce the problem, i will keep this issue open for couple of days if others have a similar issue.

We´re migrating from 6.15.8 to latest 7.16.1 or today 7.16.2 but having hard issues on that.

It´s big industry code base with tree of nested domain interfaces and causes problems even on start. It hang on typecheck, killing IDE- functionality also.

This is error message after some actions:

Files successfully emitted, waiting for typecheck results...

<--- Last few GCs --->

[13020:0000016FC5232840] 136886 ms: Mark-sweep (reduce) 1959.3 (2026.2) -> 1959.2 (1995.2) MB, 2263.3 / 0.0 ms (average mu = 0.563, current mu = 0.000) last resort GC in old space requested
[13020:0000016FC5232840] 139050 ms: Mark-sweep (reduce) 1959.2 (1995.2) -> 1958.9 (1995.2) MB, 2164.0 / 0.1 ms (average mu = 0.393, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: 00007FF71518FD2F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112495
2: 00007FF71511EEF6 v8::internal::wasm::WasmCode::safepoint_table_offset+65526
3: 00007FF71511FDAD node::OnFatalError+301
4: 00007FF715A6663E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF715A50F7D v8::SharedArrayBuffer::Externalize+781
6: 00007FF7158D15AC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
7: 00007FF7158CC3BE v8::internal::Heap::AllocateExternalBackingStore+2270
8: 00007FF7158E9C80 v8::internal::FreeListManyCached::Reset+1408
9: 00007FF7158EA335 v8::internal::Factory::AllocateRaw+37
Files successfully emitted, waiting for typecheck results...

We already changed to workaround the now missing support of recursive properties (#4055).
Even commented out this, causes the problem above.

We´re migrating from 6.15.8 to latest 7.16.1 or today 7.16.2 but having hard issues on that.

Does the issue occur at 7.16.1?

For me it only pops up in 7.16.1, I temporarily fixed it with: microsoft/TypeScript#34933 (comment)

Edit: I mean 7.16.2, no issues with this on 7.16.1

For me it only pops up in 7.16.1,

you mean 7.16.2 right? I am bit confused on which version having the issue.

For me it only pops up in 7.16.1,

you mean 7.16.2 right? I am bit confused on which version having the issue.

Apologies, yes :) Added edit to my comment

In 7.16.1 it hangs a long time and than shows the expected compile failure (Work in Progress). After a lot more time it crashes based on the heap overflow :

<--- Last few GCs --->

[29160:000001DD485AA6D0] 291025 ms: Mark-sweep (reduce) 1957.6 (2023.0) -> 1957.0 (1991.7) MB, 2521.2 / 0.0 ms (average mu = 0.683, current mu = 0.000) last resort GC in old space requested
[29160:000001DD485AA6D0] 293339 ms: Mark-sweep (reduce) 1957.0 (1991.7) -> 1956.9 (1991.2) MB, 2314.5 / 0.0 ms (average mu = 0.532, current mu = 0.000) last resort GC in old space requested

<--- JS stacktrace --->

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
1: 00007FF71518FD2F v8::internal::CodeObjectRegistry::~CodeObjectRegistry+112495
2: 00007FF71511EEF6 v8::internal::wasm::WasmCode::safepoint_table_offset+65526
3: 00007FF71511FDAD node::OnFatalError+301
4: 00007FF715A6663E v8::Isolate::ReportExternalAllocationLimitReached+94
5: 00007FF715A50F7D v8::SharedArrayBuffer::Externalize+781
6: 00007FF7158D15AC v8::internal::Heap::EphemeronKeyWriteBarrierFromCode+1468
7: 00007FF7158CC3BE v8::internal::Heap::AllocateExternalBackingStore+2270
8: 00007FF7158E9C80 v8::internal::FreeListManyCached::Reset+1408
9: 00007FF7158EA335 v8::internal::Factory::AllocateRaw+37
10: 00007FF7158FBFEE v8::internal::FactoryBasev8::internal::Factory::AllocateRawArray+46
11: 00007FF7158FEC7A v8::internal::FactoryBasev8::internal::Factory::NewFixedArrayWithFiller+74
12: 00007FF7158FEED3 v8::internal::FactoryBasev8::internal::Factory::NewFixedArrayWithMap+35
13: 00007FF7156FF9D8 v8::internal::OrderedNameDictionary::Addv8::internal::LocalIsolate+856
14: 00007FF7156FFF97 v8::internal::OrderedNameDictionary::FindEntryv8::internal::Isolate+247
15: 00007FF7156FFE24 v8::internal::OrderedHashTablev8::internal::OrderedHashMap,2::EnsureGrowablev8::internal::Isolate+100
16: 00007FF71563066F v8::internal::CompilationCache::IsEnabledScriptAndEval+5775
17: 00007FF715AF3341 v8::internal::SetupIsolateDelegate::SetupHeap+491537
18: 00007FF715ACE2DB v8::internal::SetupIsolateDelegate::SetupHeap+339883
19: 000001DD4A7759EC

With 7.16.2 it´s more weird, because it hangs long time than starts server (even with known compile errors) and later the heap overflows.

That's the thing without a reproducible codesandbox, I am playing a guessing game here, eg which version of TS, what's the type. Until someone can send a reproducible codesandobox it would be difficult for us to find out eh root cause and fix it.

I'm part of the team of @sebastian-kricke.
We will try reproduce the issue in a codesandbox tomorrow.

I will fix this 🙏

any update on reproducible codesadnbox (example)?

any update on reproducible codesadnbox (example)?

Unfortunately not, I'm trying to implement the same data structure and amount as in our project but it's not doing anything wrong yet.

which version of TS that you guys are using?

We just updated as we were starting with the RHF update. We are now using 4.4.3.

Same here, 4.4.3

Until now, we were not able to finish a sandbox reproducing the issue. It´s a bit hard to figure out how complex it needs to be.

Possibly it´s caused by not only "large" amount of data structures, but also on large amounts of forms with fields that run type checks. Today we have no capacity to increase the sandbox more. We´ll keep it in mind this week and have to balance or tasks.

thanks for the update @sebastian-kricke will keep this issue open for a while, in case someone can reproduce this issue, so we can look into it for a fix.

I'm having the same issue on v7. It occurs when using the field property from Controller's render prop. And the tree passed to render is really not that complex.

can you provide a codesandbox @bailinca ?

It seems the error type in controller.ts could be your issue @bluebill1049 , as you introduce a recursive conditional type. See 12d8dfe

I believe I'm also seeing this issue in some manifestation after upgrading to 7.17.1. I have a utility function in my project that normalizes FieldError into a string[]:

// typeof normalizeFieldError: (error: FieldError) => string[];
const controlReturn = useController({ control, name });

<ListOfFieldErrors
  errors={normalizeFieldError(controlReturn.fieldState.error)}
/>

Passing controlReturn.fieldState.error into normalizeFieldError gives back a very long recursive error that boils down to:

Property 'type' is missing in type 'DeepMap<{ [$NestedValue]: never; } & object & { [K in keyof (readonly any[] & PathValue<TFormFields, TName>)]: UnionLike<(readonly any[] & PathValue<TFormFields, TName>)[K]>; }, FieldError>' but required in type 'FieldError'.

Attempting to assert controlReturn.fieldState.error as FieldError is apparently pointless according to eslint but they don't work on the latest TS version so perhaps the warning isn't accurate:

This assertion is unnecessary since it does not change the type of the expression.

I can try to create a repro of this in codesandbox if it would be helpful.

@jviall if you can provide a CSB would be great.

thanks very much @getTobiasNielsen for the investigation, i will have a look at today.

It's happening in my codebase with react-hook-form 7.17 and even 7.18.0-next.0.
I tried TypeScript 4.4 and 4.5.0-beta.

I tried hard to reproduce it in CodeSandBox but I couldn't. The reason might be that CodeSandBox loads only some default VSCode version of TypeScript. I tried overriding the TS SDK version in settings and it didn't let me.

My sample component looks a bit like the following if you want to try it in new CRA app in VSCode:

import { useForm, Controller } from "react-hook-form";

type FormFields = {
  p1?: boolean;
  p2?: string | null;
  p3?: boolean;
  p4?: number[] | null;
  p5?: string | null;
};

export default function App() {
  const methods = useForm({
    defaultValues: ({} as any) as FormFields,
    context: {}
  });

  const { control } = methods;

  let defaultValue: boolean | undefined = false;

  return (
    <form>
      <Controller
        control={control}
        name="p1"
        defaultValue={defaultValue}
        render={({ field }) => <input value={field.value?.toString()} />}
      />
      <input type="submit" />
    </form>
  );
}

I tried eliminating the undefined bit but it didn't help.

BTW, my project is using emotion for JSX. I wonder if this is a factor, but even if, it's only happening with a specific case of a Controller. Other controllers seem to be fine. (spoke too soon, other Controllers had the same issue now too).

I've also seen it in earlier versions. At this stage it seems that a potential workaround might be using the useController hook instead of the Controller component. I've also seen this in the provider, but as soon as I removed the Controller inside it, it was fine.

@Meligy does it happen at 7.17.2?

@Meligy does it happen at 7.17.2?

Yes

@Meligy does it happen at 7.17.2?

Yes

maybe this comment helps: #6753 (comment)

maybe this comment helps: #6753 (comment)

Thanks. I did see it yeah, and am confirming the findings there. Interestingly it seems across a wide range of versions for both react-hook-form and TS :(

HI,
Did anyone get performance issues using vscode?. Because after starting getting this error I started making some investigations and as a result, I started seeing a pattern where in my code editor when going to file that has component vscode starts acting weird in getting suggestions or going to another file that is imported... things like that.

What I am trying to say is maybe there are some memory leaks that are coming from the library. Down you have a screenshot from my code editor with the error:

Unable to get suggestions:

Going to address and improve TS performance in V8, RFCs:

#7354
#7389

on my branch where I installed react hook form, with tsc --extendedDiagnostics I am seeing double the amount of type instantiations than the integration branch, and the compilation time also doubled from 8 secs to 16 seconds and also have massive lag for vscode intellisense, I hope V8 won't have these issues.

What could be done in V7? We're trying to migrate from formik, but Webstorm goes into 100% cpu and mem perpetually. It's unusable.

Using either watch or control gives me "TS2589: Type instantiation is excessively deep and possibly infinite." and unresponsive Webstorm. I'm on Typescript 4.6.3 bundled with Webstorm and react-hook-form 7.31.1.

It seems like Path type is problematic one. I also get a lot of errors like TS2615: Type of property '<some prop>' circularly references itself in mapped type '{ [K in keyof <some type which has the prop>]-?: PathImpl ; }'.

@KazimirPodolski try with v8, TS performance is getting address and v8 breaking change is minimal as well.

@bluebill1049 It worked just fine, thanks.

@KazimirPodolski try with v8, TS performance is getting address and v8 breaking change is minimal as well.

I'm facing the same issue, my project stopped to compile for some reason.

Is there any migration guide or documentation for the V8?

What's the ETA for a stable release?

Can it be used in production safely ?

There're a couple of TS perf issues in the current v8 version. No ETA for now