Hey everyone! 👋
I've been using Aider for a few months now and generally love it for single-project tasks, but I've hit a consistent snag when trying to use it with our company's monorepo. It seems to really struggle with the context across multiple, interconnected packages.
My main issue is that when I ask it to modify a function in one package, it often fails to understand the imports or dependencies from sibling packages. It'll make a change that looks correct locally, but then breaks the build because it didn't consider how other parts of the repo rely on the original interface.
Has anyone else run into this? I'm wondering if it's:
* A context window limitation—maybe it's just not pulling in enough of the relevant files from across the package boundaries?
* Something about how it parses the project structure at the start of a chat?
* Or is there a specific way to configure `.aider*` files or the initial prompt to help it understand the monorepo layout better?
I'm currently working in a pnpm workspace with a pretty standard structure (apps/, packages/, etc.). I usually start Aider from the root.
Would love to hear if others have found workarounds or best practices for this. It's such a powerful tool, and I'd hate to have to drop it for monorepo work.
Happy hacking!
Happy hacking!
Yeah, that context window limitation is a real killer with complex monorepos. I've found you really have to hand-hold it.
What sometimes works for me is starting a new chat session and explicitly adding the key interface files from other packages first, before asking for the main edit. It's a bit manual, but it forces the right context into the window. The `.aider*` files help for project-wide rules, but they don't solve the immediate "need to see package B" problem in a single request.
Have you tried giving it a super explicit map of the workspace in your first prompt? Like a quick text diagram of the apps and packages folders? It's hit or miss, but it can set the stage better.
Totally agree about the hand-holding. That explicit map idea is clever - I've done something similar by pasting the output of a quick `find . -type f -name "*.py" | head -20` to give a bird's eye view at the start.
A related trick I use is creating a small, temporary README.aider.md in the root. I'll just list the package/ service relationships there in plain text and then `/add` it at the beginning of the session. It feels like giving the model a tiny, project-specific wiki.
Have you found that the diagram approach works better for certain types of changes, like API contract updates, versus internal refactors?
YAML is not a programming language, but I treat it like one.
Oh, that README.aider.md idea is brilliant! I've been struggling with the same thing in our monorepo. I'll have to try that.
Do you find it helps Aider avoid those weird circular import suggestions it sometimes makes? I've had it try to add an import from a package that *itself* imports the file it's editing, which just creates a mess. Maybe laying out the dependencies plainly upfront would prevent that.
The temporary README trick can indeed mitigate some circular import issues by providing a static dependency map, but it's not a complete solution. I've observed that Aider, when processing a complex edit, often references its internal representation of the code more than the static documentation you've provided upfront. The README sets an initial directional intent, like "package A depends on B," but the model can still get lost in the syntactic details during the actual code generation step.
A more effective, albeit labor-intensive, method I've used is to preemptively add the specific interface files from upstream dependencies to the chat context using `/add` before making the edit request. This gives the model the concrete signatures it needs. The README approach reduces the frequency of circular logic, but in my experience, it doesn't eliminate it - you're still relying on the model to correctly interpret a text description against the actual code it's manipulating.
Always check the data transfer costs.