-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange output from tsc noEmit
- unclear where error stems from within app,
#46277
Comments
This looks like a typescript crash |
@tomdev10 it's not telling you that you have an error, it's tripping over itself and crashing in a way that it should never do. Can you provide a repo where this happens? |
Hi @andrewbranch @AlCalzone - thanks for the speedy reply. I can try and produce a repo, but will take me a bit of time as the content is sensitive so will need to try and remove that. I know it might be like asking a million dollar quesiton, but any idea what might be causing it? I was wondering if it was clashing typescript versions within the deps somehow? |
From the stack, we can tell that what’s happening is that a parse tree node is ending up in the data that we are attempting to serialize into a .tsbuildinfo file. But that should never happen, and finding out why it’s happening is likely to be very very difficult without a debuggable repro, and probably very easy with one. |
Okay fair comment, that makes sense. I will do my best to get one up and running - thanks! Will try and get it done this week. Inidentally, trying to figure this out myself I came across |
No, |
Hey, |
Hi @val1984 + et al. I never actually traced this, or got to the bottom of what caused it. However, I did solve it within my repo, by removing all After this, it worked. You've done a better job tracing than I have so far, so I'll leave the issue open FYI @andrewbranch |
@val1984 that’s a pretty good start. Did the problem not reproduce with |
But it does result in the same error as soon as I'm able to run my project when disabling |
I can't reproduce this just by installing reselect@4.1.1, importing it, and compiling with Barring all that, I think we’ll just have to let this issue sit and see if someone comes up with a shareable repro. |
Actually let me go ahead and do this so you can try it before you get into a state where it doesn’t repro anymore. Here is a copy of tsc.js from typescript@4.4.4 with the line added at 86695: console.log(require("util").inspect(buildInfo, { depth: 32 })); If you have time to try it, you’ll need to download it and drop it into |
Hey @andrewbranch, |
@val1984 nothing in that log looks like a problem, so maybe it did truncate the relevant parts... just to confirm, did it crash with |
Correct ✔ |
Ok, let’s try this function getBuildInfoText(buildInfo) {
try {
return JSON.stringify(buildInfo);
}
catch (err) {
console.log(require("util").inspect(buildInfo, { depth: 32, maxArrayLength: Infinity }));
throw err;
}
} Can you replace |
@andrewbranch The file weighs 134MB, any idea how to transmit it to you? Or maybe I can filter out most data? |
You can email it to me if you want— |
@andrewbranch Sorry, I'm not yet able to share the log with you. |
@val1984 feel free to redact any source file text from the log that makes it a problem to share. What I need to do with it is figure out the path from the top level of that object to the Node object, which shouldn’t be in there. I’m guessing when you look at it, you see a huge repeating cycle. I just need to trace that cycle to the top. |
Hey @andrewbranch , we are also experiencing this build crash. Our log with your code snippet from 15 Nov 2021 is 128MB big with more than 170k lines. We have a NextJS application with formerly Preact working fine as intended. We are now willing to switch back to React, and now this error occurs during build. I also tried some older versions of typescript@4.* and the current nightly (2nd January) but with no luck. I might can send you the log via email, but I need to talk to team members before. |
Hey @andrewbranch, we figured out what the problem is. We had a component, which was included with dyanmic-Import from NextJS. In the imported Component we had a type When we resolved the dynamic import to a normal import, we get the correct message from typescript Best, Florian |
@fmacherey I’m glad you found a workaround, but you didn’t find “the problem” per se. The problem is and will forever remain a mystery until someone can send me that gigantic log file. |
@andrewbranch just to clarify, I used the normal import for debugging, but switched back to dynamic after fixing the types. I think typescript has problems with next' dyamic import to correctly resovle the types. |
This really has nothing to do with imports, resolving types, Next.js, incorrectly supplying an array where a single child should go, or any particular piece of end-user code. There is a very strange bug with serializing complex state during incremental builds, and you’ve happened to find a lever on one end of a Rube Goldberg machine that toggles the problem from a mile away. What’s happening between between that lever and the real problem is not inferable by a human. All I can tell you is that the lever itself is not relevant on its own, or attached to any other machine except the precise one made by your program, and the only way we can understand what’s happening is by observing the whole machine. I have tried to encode clues about its operation in the log file generated by the patched TS version I made, but I’ve yet to see one of these logs |
@andrewbranch I just hit this in a similar setup. I'm using Next.js with Yarn PnP. I was also messing with Here's a link to the output of running This is what happens without the logs: /Users/dgattey/checkouts/dg/.yarn/cache/typescript-patch-0b90225f97-2e488dde7d.zip/node_modules/typescript/lib/tsc.js:88443
return JSON.stringify(buildInfo);
^
TypeError: Converting circular structure to JSON
--> starting at object with constructor 'Node'
| property 'statements' -> object with constructor 'Array'
| index 0 -> object with constructor 'Node'
--- property 'parent' closes the circle
at JSON.stringify (<anonymous>)
at getBuildInfoText (/Users/dgattey/checkouts/dg/.yarn/cache/typescript-patch-0b90225f97-2e488dde7d.zip/node_modules/typescript/lib/tsc.js:88443:21)
at emitBuildInfo (/Users/dgattey/checkouts/dg/.yarn/cache/typescript-patch-0b90225f97-2e488dde7d.zip/node_modules/typescript/lib/tsc.js:88248:67)
at ... EDIT: yea as suspected, it's from This wasn't an error I was seeing live in VSCode until I cleared my yarn cache and reinstalled all yarn packages... but I'm going to chalk that up to Yarn PnP being buggy. I'll leave https://github.com/dgattey/dg/tree/andrew/debugging for you to debug and test in this state. |
Thanks @dgattey—as I suspected, that file shows me exactly what the problem is 🎉 |
Bug Report
Hi all. Relatively new to TypeScript, but just trying to understand this output from
tsc
but I can't seem to get to the bottom of it. Please see terminal output below after runningtsc
command - appears error is in library code, rather than in app - but I'd expect a stack trace or similar to find the type error, but in fact there doesn't seem to be one?Typescript tools in VSCode show no error in any files - does anyone have any idea what is causing this?
🔎 Search Terms
JSON errors, noEmit, tsc type check, version info, circular structure, "parent", "statements"
🕗 Version & Regression Information
💻 Code
🙁 Actual behavior
This should produce output showing where the error is, rather than displaying either this global error, or something is wrong in the library.
🙂 Expected behavior
I'd expect more detailed info, but I might be wrong...?
The text was updated successfully, but these errors were encountered: