Alright, let's be real. The marketing for Cline makes it sound like it just *gets* your codebase, especially if you whisper "monorepo" in its general direction. Our experience was decidedly less magical. Getting it to function with our fairly standard pnpm workspaces setup required more configuration archaeology than I'd like to admit.
The main hurdles weren't the core chat, but getting the context right. The out-of-the-box settings assume a single package.json at the root, which is useless when you have a dozen services and shared libraries. Here's what we had to piece together:
* **The `.clineignore` is non-negotiable.** You need one at the monorepo root that actually reflects your structure. Ours excludes build artifacts, node_modules (except the root one, which is tricky), and configuration directories for other tools.
* **Forget the auto-context.** The feature that lets Cline "see" relevant files based on your chat? It kept pulling in types from three services away. We had to be explicit. The `@` referencing works, but you have to train the team to use full relative paths from the root.
* **Workspace awareness is a manual process.** Cline doesn't inherently understand pnpm or npm workspaces. You have to point it at the specific `package.json` of the service you're working on for it to have any hope of understanding dependencies. This means changing the "project root" in your mind, or in the config, depending on which slice of the monorepo you're tackling.
The biggest pitfall was cost, indirectly. Once we got it configured, the team started using it more—great, right? Except the context windows ballooned because it was pulling from across the monorepo. Our API token usage spiked. So you're not just configuring for functionality, you're configuring for FinOps unless you want a nasty surprise on the monthly invoice.
In the end, it works. But "just works"? Not even close. It feels like we're beta-testing monorepo support that was announced as a flagship feature. The value is there for boilerplate and isolated refactors within a single service, but for cross-workspace tasks, you're still the one holding the map.
Question everything
Hit the same wall. That auto-context feature is worse than useless in a monorepo - it adds noise and kills any chance of a relevant answer.
Your point about the root node_modules is key. The ignore pattern needs to be surgical:
```
**/node_modules/**
!node_modules/
```
Otherwise it strips all dependency context.
We ended up disabling auto-context entirely and forcing explicit @ references. It's manual but at least it's accurate.
slow pipelines make me cranky