Open dragomirtitian opened 4 months ago
Generally, I feel like it'd be even better to always emit some sort of declaration error whenever declaration emit synthesizes an any
out of nowhere...
I'll open a PR after 5.5. I tried locally and there are several places that now have errors, but in my opinion they are all good. Maybe we have just a carveout if someone is not using noImplicitAny
(although hopefully nobody is actually doing that 😅)
I think this is the same issue I'm having, but I'm not sure.
UPDATE: I figured out my own issue - my library's type declarations were being created with import type {...} from "@/jrfs";
because I don't have anything in place to fix tsc
created alias import paths. Once I changed those to use relative import paths it worked. So, never mind, sorry for the noise!
🔎 Search Terms
declarations recursive types
🕗 Version & Regression Information
⏯ Playground Link
Playground Link
💻 Code
🙁 Actual behavior
In declarations, the type for
a
is printed asa: () => T extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? V extends (infer V)[] ? any : V : V : V : V : V : V : V : V : V : V : T;
🙂 Expected behavior
Recursive
can't be represented without falling back toany
(as seen above) so it should just be an error instead of silently toany
Additional information about the issue
Related to #55832