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)
@andrewbranch I just hit this in a similar setup. I’m using Next.js with Yarn PnP. I was also messing with
childrenin some component I was editing, and restricting the types of children that could be passed.Here’s a link to the output of running
tscwith a replacedbuildInfo. 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:
EDIT: yea as suspected, it’s from
./src/components/homepage/ColorSchemeToggleCard.tsxbecauseThis JSX tag's 'children' prop expects a single child of type 'Children', but multiple children were provided. The typeChildrenthere is from./src/components/ContentCard.tsxand it’s just a union ofReactElement,null, andundefined.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 ☹️.
@val1984 that’s a pretty good start. Did the problem not reproduce with
tsc, or do you just not normally usetscas 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.jsonfiles (it was a monorepo) and regenerating those. Some contributing to the repo had been runnningnpm audit fix --forceand 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 byfork-ts-checker-webpack-plugin@6.4.0. I’ve narrowed down the issue to being caused by usingreselect@4.1.1in 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
extendedDiagnosticsand this showing that all thenode_modulesare being type chcked, wondering if this might be why? Or if there is any useful output avaliable from this aid where to look?