Petr Kratochvíl, thanks for the post inspiration and for letting me share this interesting story :D
It was a Thursday evening. I was sitting at home, playing my guitar, when suddenly a notification popped up – Petr had messaged me on LinkedIn, asking if I had a moment to help solve a frustrating problem in the NX ecosystem – a painfully slow IDE. I thought, “Sure, brother, schedule the meeting and let’s go!”
Petr’s project was quite large (though not huge) – its size definitely didn’t justify such a slow IDE. Sometimes, very large NX projects (no matter what you do) can still feel sluggish in the IDE — especially when you add AI-based typeahead (Cursor/Copilot) into the mix. That can create a major bottleneck, and often the only solution is to work with “namespaces” — but that’s a story for another time.
As a clue, Petr mentioned that the issue had started about two months ago. That immediately ruled out the project size as the cause — it hadn’t grown that much during that time. Previously, everything had been running razor-fast.
We had a few suspects:
<ol>
<li>
Misconfigured tsconfig in the projects
</li>
<li>
Cyclic dependencies
</li>
<li>
Incorrectly configured package.json / nx.json files
</li>
<li>
HUGE TypeScript types (or rather, their unions)
</li>
</ol>
The only way to confirm it was to roll back commits to about two months ago and search for the culprit — ideally using a halving method: first 2 months back, then 1.5, then 1, narrowing down the range where the issue began.
The culprit turned out to be the next-intl library used for translations. How was it fixed? In this case, the only reasonable solution was a types removal (for quick fix), replacement later.
But why does this happen in the first place?
TypeScript unions are costly for the TS server — they require constant recalculations (I described this in detail in my article, so I won’t go deep into it here).
In short: the more unions and complex type inference you have (e.g., with zod, custom abstractions, trpc, etc.), the higher the risk your IntelliSense will start burning — especially when you have massive generated types. In the article, I describe how to avoid this.
You can read the full case study here:
<a href="https://lnkd.in/dFAEzgYM" target="_blank" rel="noopener nofollow">https://lnkd.in/dFAEzgYM</a>
PS: Petr Kratochvíl, I was genuinely impressed by how fast you navigate through the IDE! I haven’t seen that kind of speed in a long time — and it was already well past 5:00 PM. You must’ve had a lot of coffee 😄 And if that’s your normal pace, full respect! ☕🔥

We are a company dedicated to providing mentorship, education, and consultation in web technologies such as React, Cypress, Node, AWS, and more. Visit our website or contact us for more info

greenonsoftware

A debugging story about resolving severe IntelliSense slowdowns in an Nx monorepo. The root cause was traced to the next-intl library generating massive TypeScript union types that overwhelmed the TypeScript language server. The investigation used git bisection to narrow down when performance degraded, ruling out project size, cyclic dependencies, and configuration issues. The solution involved removing problematic type definitions, highlighting how complex type unions and generated types can create IDE performance bottlenecks in large codebases.

Fixing IntelliSense Performance Issues in Nx and Turborepo

Not sure, where the hype comes from about Monorepos. Just because Facebook made a big announcement about it or what? They use their own version control system, so it’s a different story there.
I’ve worked with a lot of Monorepos in the past, at work. Right now, I’m working with each repository being one thing and in my free time I’ve always been doing this.
So, I have extensive experience with both methods and I can 100% confirm, that in my experience, using one repository for one thing, instead of a Monorepo, is pretty much always better.
I’ll spare you the technical details, as they are obvious. I will argue for it on an abstract level, to get the concept across.
If you have 10 squishy balls, you can always choose to squish some of them together, if you need a bigger one. No problem. However, if you have one huge ball, try to split it int 10 equally pretty, equally sized and equally shaped balls. It’s very difficult.
Same with Monorepos. If you need all the stuff in it, fine, maybe it helps. But if you usually work on one thing only, like e.g. one “folder” in that Monorepo, then you deal with so many changes and extra stuff, you don’t need and sometimes even breaks some IDE functionalities, depending on the situation.
Long story short, if you don’t have a really really great super duper reason for using a Monorepo, then don’t. Every repository should do one thing. One thing well. That’s it. That’s the way to go.
Replace Monorepos with Workspaces, like the ones in Visual Studio Code and Git submodules, etc.

Really good article.
Monorepos are my favourite way to setup projects now and since not too many people talk about them, it is good to come across this kind of stories.
“e.g., with zod, custom abstractions, trpc, etc” this. This. This, man. This is so true. I can’t describe, I can’t talk 🤣🤣🤣. The thing would work like one day ago and suddenly it breaks, <code>trpc</code> type safety lost. It can get pretty complicated with the tsconfigs. This is a whole rabbit hole. And still we want monorepo.
In your case it was a complex type that slowed down the TypeScript Language Server. And from the article I going to “steal” the analysis tools you mentioned such especially the dependency graph analyser. I’m going to look if Turborepo has one.
Usually my custom setup would be : Nestjs for the backend and Vite/Nextjs/astro for the frontend. And I use trpc in the middle because why use a ts monorepo if I can’t have end to end type safety ? I really like to get the best of both worlds: typesafety from trpc procedures and the modularity of Nestjs.
And sometimes wire up all that together can be tricky. In my case for example, since Nestjs is commonjs only (at least for the moment, I think), I had to do some weird gymnastics to have the type output of the trpc <code>AppRouter</code>: generate the <code>.d.ts</code> files in a common package from where I export the <code>AppRouter</code> to use it in the frontend(s) app(s), otherwise when the <code>AppRouter</code> type is imported in the frontend it is typed as <code>any</code> xD. Pretty interesting to make all that work, mess around with the tsconfigs here and there 🤣.
The other day I had an issue with an astro app where everything (trpc type safety) was working just fine and suddenly broke. The culprit: I forgot to use the references in the tsconfig (you talked about that in the article too). Those subtle bugs can be tricky to find. But overall I like monorepos and I want to keep using them.

Very on point, thank you for sharing

Don’t tell me that… i just started the final project of my degree as a monorepo 😵