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

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…?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 27 (14 by maintainers)

Most upvoted comments

@andrewbranch I just hit this in a similar setup. I’m using Next.js with Yarn PnP. I was also messing with children in some component I was editing, and restricting the types of children that could be passed.

Here’s a link to the output of running tsc with a replaced buildInfo . It’s happening on this branch of my personal website repo if you want to explore source code! Thanks!

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 ./src/components/homepage/ColorSchemeToggleCard.tsx because This JSX tag's 'children' prop expects a single child of type 'Children', but multiple children were provided. The type Children there is from ./src/components/ContentCard.tsx and it’s just a union of ReactElement, null, and undefined.

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 🎉

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 ☹️.

Rube Goldberg machine as a TypeScript program

@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?

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 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 @andrewbranch

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.

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?