Skip to content
Notifications
Clear all

Guide: Making Claude Code work with our monorepo setup (PNPM, Turborepo).

9 Posts
9 Users
0 Reactions
15 Views
(@cloud_cost_owen)
Reputable Member
Joined: 5 months ago
Posts: 181
Topic starter   [#22719]

Just got Claude Code humming with our massive PNPM + Turborepo monorepo. It was a bit fussy at first, but the payoff is huge for navigating and refactoring across packages. Here's the config that did the trick.

The key was setting up the `claude_desktop_directories` config correctly and telling it to ignore the massive `node_modules` at the root.

**My `claude_desktop_config.json`:**
```json
{
"claude_desktop_directories": [
"/Users/owen/dev/monorepo/packages/app",
"/Users/owen/dev/monorepo/packages/ui",
"/Users/owen/dev/monorepo/packages/shared",
"/Users/owen/dev/monorepo/tooling"
],
"default_ignore_patterns": [
"**/node_modules",
"**/dist",
"**/.next",
"pnpm-lock.yaml"
]
}
```

**Important:** I added the monorepo root itself to the "Never index" list in Claude Code's settings, to prevent it from trying to crawl everything and getting stuck on the root `node_modules`.

Now I can:
* Ask for changes across multiple packages in one request
* Get accurate imports and dependency tracking
* Refactor shared types/library code with confidence

Anyone else running a similar setup? What patterns are working for you?

#savings



   
Quote
(@ci_cd_enthusiast)
Honorable Member
Joined: 7 months ago
Posts: 382
 

Nice trick with the "Never index" on the root! That root `node_modules` is a real killer for performance.

One thing I'd add - have you also pointed Claude at your `pnpm-workspace.yaml`? In our setup, giving it that file seemed to help it understand the package relationships a bit better from the start.

How's the performance for you now? Any plans to integrate those cross-package refactors into your CI pipelines?


Pipeline Pilot


   
ReplyQuote
(@alexh42)
Reputable Member
Joined: 3 months ago
Posts: 227
 

Great tip on the "Never index" setting, that's exactly what made the difference for us too. The indexing would grind to a halt without it.

I found pointing Claude at the `pnpm-workspace.yaml` was a mixed bag - it helped with understanding dependencies conceptually, but sometimes led to odd suggestions for local package imports until it fully indexed the actual package contents.

Performance-wise, it's solid for navigation and refactoring now, but we're not quite ready for CI integration. I'm worried about the non-deterministic nature of some of its suggestions, especially around exports. How are you handling the confidence level on cross-package changes?



   
ReplyQuote
(@ci_cd_plumber_42)
Reputable Member
Joined: 4 months ago
Posts: 257
 

Exactly right about the non-determinism being a blocker for CI. We tried a similar setup for automated code reviews and had to dial it back.

The confidence problem with exports is real. Claude would sometimes change `export { Thing }` to `export type { Thing }` incorrectly, breaking runtime code. Our workaround was to only use it for PR descriptions and dependency change analysis, never for direct refactors in the pipeline.

Have you looked at coupling it with a stricter TypeScript check or a test run as a safety net for any suggested changes? That's our next experiment.



   
ReplyQuote
(@annas)
Honorable Member
Joined: 2 months ago
Posts: 542
 

Glad you got the indexing under control. Your config is a solid starting point, but you're missing the most critical piece for a Turborepo: the root `turbo.json`.

If you don't include it, Claude won't understand your pipeline dependencies or cached outputs, which leads to suggestions that break your build topology. I learned this the hard way when it suggested moving a shared util into a package that was a dependency of half the graph, which then invalidated the cache for every downstream task.

Add the root config directory to your `claude_desktop_directories`, or at least symlink the key files. Also, consider adding `**/.turbo` to your ignore patterns unless you want it analyzing cache artifacts.



   
ReplyQuote
(@cloud_ops_learner)
Honorable Member
Joined: 4 months ago
Posts: 419
 

Oh, adding `turbo.json` is a great point, I hadn't thought of that. The cache invalidation issue you mentioned sounds like a real headache.

Would that also mean it should see the root `package.json`? Since that's where the main turbo script usually lives, right?

And yeah, adding `**/.turbo` to the ignores makes total sense. Don't need it getting confused by cache files.


Still learning


   
ReplyQuote
(@data_shipper_joe)
Prominent Member
Joined: 5 months ago
Posts: 680
 

Good call on the root `package.json` - yeah, you should include it. The turbo script is there, and it often has the workspace packages listed too. Claude can get weird about inter-package imports if it doesn't see the workspace definition.

One caveat I found: if your root `package.json` has a bunch of scripts for managing the monorepo, Claude might sometimes suggest running them from a sub-package context where they wouldn't work. Just something to watch for.

And absolutely seconding the `**/.turbo` ignore. It started trying to "fix" cache files for me once 🤦‍♂️.


ship it


   
ReplyQuote
(@graces)
Reputable Member
Joined: 3 months ago
Posts: 441
 

Thanks for sharing this configuration, it's really helpful to see a real-world example that's working. The "Never index" tip for the root directory is exactly the kind of practical fix that makes all the difference with these tools, and I'm glad you called it out explicitly.

I've noticed a similar pattern where including the tooling directory pays off, especially for shared ESLint configs or TypeScript base configurations. Claude gets much better at suggesting consistent lint fixes or understanding extended type rules when it can see those files. Have you found it helps with maintaining consistency across packages?

The excitement about cross-package refactors is totally understandable, but I'd gently add a note of caution from what others have mentioned: it's wise to pair these big changes with a solid pre-commit or CI check. The confidence in the tool grows a lot when you know a test run will catch any export mix-ups.


Stay curious.


   
ReplyQuote
(@brianw)
Reputable Member
Joined: 3 months ago
Posts: 242
 

You're spot on about the tooling directory. In our setup, the shared ESLint config lives there, and Claude's suggestions for fixing lint violations became noticeably more accurate once it could reference the actual rule definitions. It stopped suggesting fixes that would conflict with our custom airbnb-base extensions.

The pre-commit check is essential, but we've found it's not just about catching errors. We run a specific script after any Claude-assisted refactor that calculates the incremental change in bundle size for affected packages. It's saved us from a few "correct" refactors that would have unintentionally bloated our core library by pulling in new dependencies across package boundaries.


Spreadsheets or it didn't happen.


   
ReplyQuote