Strange output from `tsc noEmit` - unclear where error stems from within app,

[tomdev10]

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 running tsc 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

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about tsc output with noEmit
• Tested on 4.4.3 and typescript@next

💻 Code

> tsc --noEmit

/frontend/node_modules/typescript/lib/tsc.js:88155
        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 (/frontend/node_modules/typescript/lib/tsc.js:88155:21)
    at emitBuildInfo (/frontend/node_modules/typescript/lib/tsc.js:87960:67)
    at emitSourceFileOrBundle (/frontend/node_modules/typescript/lib/tsc.js:87926:13)
    at forEachEmittedFile (/frontend/node_modules/typescript/lib/tsc.js:87685:28)
    at Object.emitFiles (/frontend/node_modules/typescript/lib/tsc.js:87900:9)
    at Object.emitBuildInfo (/frontend/node_modules/typescript/lib/tsc.js:94075:33)
    at Object.emitBuildInfo (/frontend/node_modules/typescript/lib/tsc.js:96965:67)
    at Object.handleNoEmitOptions (/frontend/node_modules/typescript/lib/tsc.js:95814:25)
    at Object.emit (/frontend/node_modules/typescript/lib/tsc.js:97015:29)

🙁 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...?

[AlCalzone]

This looks like a typescript crash

[andrewbranch]

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?

[tomdev10]

Hi Andrew Branch (@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?

[andrewbranch]

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.

[tomdev10]

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 extendedDiagnostics and this showing that all the node_modules are being type chcked, wondering if this might be why? Or if there is any useful output avaliable from this aid where to look?

[andrewbranch]

No, --extendedDiagnostics probably won’t tell you much. There’s no rational explanation you can conjure for why this is happening because it’s just a bug, probably caused by a silly mistake somewhere.

[val1984]

Hey,
I'm experiencing the same issue, using typescript@4.4.4, called by fork-ts-checker-webpack-plugin@6.4.0. I've narrowed down the issue to being caused by using reselect@4.1.1 in our case. Versions 4.0.0 and 4.1.0 do not cause this issue.
Hope it will help reproducing this issue as I can't share my employer's code either.

[tomdev10]

Hi Valentin (@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 package-lock.json files (it was a monorepo) and regenerating those. Some contributing to the repo had been runnning npm audit fix --force and this was causing dependancies to update in an uncontrolled fashion.

After this, it worked.

You've done a better job tracing than I have so far, so I'll leave the issue open

FYI Andrew Branch (@andrewbranch)

[andrewbranch]

Valentin (@val1984) that’s a pretty good start. Did the problem not reproduce with tsc, or do you just not normally use tsc as part of your workflow?

[val1984]

tsc does not exhibit the issue with:

"compilerOptions": {
  "incremental": false,
  "noEmit": true,
  "pretty": true
}

But it does result in the same error as soon as incremental is set to true.

I'm able to run my project when disabling incremental mode (and I have type errors on my project because reselect@4.1.0 included some breaking changes). I'll fix them and let you know if this solves the crashing issue with incremental mode.

[andrewbranch]

I can't reproduce this just by installing reselect@4.1.1, importing it, and compiling with incremental, but it feels like we're so close. The compiler shouldn't crash like this under any circumstance, so the best thing would be to get a minimal repro that does crash so I can investigate what's going wrong. Valentin (@val1984) if you're able to extract that, it would be incredibly helpful. I could also probably send you a custom build that logs out everything it’s trying to serialize into build info and maybe that would narrow it down 🤔

Barring all that, I think we’ll just have to let this issue sit and see if someone comes up with a shareable repro.

[andrewbranch]

I could also probably send you a custom build that logs out everything it’s trying to serialize

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 ./node_modules/typescript/lib/ so it can find the lib.d.ts files in the same folder. Then run tsc as normal, and it will spit out a huge blob of JSON-esque output. That blob is not supposed to contain any actual source code, but the crash indicates that it might—feel free to sanitize the output before sharing it; the overall structure should give me a clue as to what’s happening.

[val1984]

Hey Andrew Branch (@andrewbranch),
Sorry for the long delay in replying. My project has about 100k loc and it seems that parts of the output are cut with:
... xxx more items
Is it enough data for you to investigate? Otherwise, what should I do to get you the data you asked?
Thank you very much!
debug.log

[andrewbranch]

Valentin (@val1984) nothing in that log looks like a problem, so maybe it did truncate the relevant parts... just to confirm, did it crash with TypeError: Converting circular structure to JSON right after that output?