Repository navigation
Correct Way to Onboard a Monorepo #208
Description
Serena works great! Thank you for this. Do you have instructions for onboarding a monorepo with multiple languages? I am using Claude code. My first attempt indexed the parent directory and nothing in the backend. The second attempt to onboard indexed the backend directory and that works, but only in the backend. I can get the same results for the frontend. It would be great to be able to use Serena on both the frontend and backend at the same time.
Directory structure:
learndolearn/
|----backend (Python)
|----frontend (Typescript)
Reacted by Milan4747, Faolain, Mansur Segmen, Austin and cm-dyoshikawa
Activity
MischaPanch commentedon Jun 21, 2025
Serena will support monorepos when #192 is finished. That should happen soon! Until then, I'd recommend treating the two directories as separate projects
leogodin217 commentedon Jun 21, 2025
Thanks. This is awesome!
mjshea-ryoma commentedon Jun 22, 2025
Do we know what the current behavior is if you do try to onboard a monorepo?
I'm running into an issue where serena is constantly timing out and requiring a language server restart, even when I indexed prior to starting claude code. I suspect it might be due to the monorepo structure of java and typescript together.
MischaPanch commentedon Jun 22, 2025
@mjshea-ryoma
Currently in a monorepo setup serena will just use the most prevalent language. So in your case either typescript or java. You can check (and adjust if needed) which one in
.serena/project.ymlCould you describe what causes the timeouts and paste the logs in a new issue pls?
IgnisDa commentedon Jul 16, 2025
Hi, thanks for the confirmation. Is there any update on this? I have a rust + typescript monorepo and have many interconnected subdirectories so does not make sense to treat each as a different project.
MischaPanch commentedon Jul 16, 2025
Hi @IgnisDa.
The conversation is going on in the PR itself. Have a look here: #192 (comment)
We have a working first version of the jetbrains extension, and will likely publish it within the next weeks. This will generally bring major improvements and extension of capabilities of Serena
taqtiqa-mark commentedon Oct 11, 2025
MischaPanch commentedon Oct 11, 2025
We will think about how to best support multiple languages with LS withing serena in the next month. It's in principle possible, just needs to be done carefully and we need to think about how (and whether) it fits into the roadmap. We realize that it's a much thought after feature.
Serena already delegates almost all core logic to the LSP, indexing is not the problem for this feature
techjoec commentedon Oct 26, 2025
yeah to me this is pretty much a full blocker to use it. I tried to use it but pretty much...every app I develop with codex has at least 2 major languages used. I should maybe restructure new projects better, but this seems like a huge blocker.
I read all the issues about how 'hard' it is to do this, but I still don't understand where the gotcha really is. I saw a comment about resource constraints running multiple LSPs, but with the price of ram and hosted solutions, and the fact I work on many repos at once (I use a dedicated 'codex' physical box with VMs and containers and stuff..), I feel like that price would be worth it!
Is there a better place to discuss this? I'd be willing to brain storm (or at least learn..) as this tool would be way more useful to me if it could handle multiple languages at once. First idea I was thinking about was a kind of "LSP bridge" so folks could create their own far-ends, and when the bridge was configured Serena would pretty much delegate LSP calls out? I am new to MCP topology and stuff but I mean if Serena had an expected schema for returned data from a function/tool it calls, and tool returned it, where's the catch in where it wouldn't play well with Serena how it is today? #339 (comment) That diagram is kind of how I see it working; the adaptor will detect what to use, when, and where, and invoke the right calls as a proxy to abstract anything unique to the 'other' LSPs into a standard shape it accepts? Too good to be true??
taqtiqa-mark commentedon Oct 26, 2025
taqtiqa-mark commentedon Oct 26, 2025
@MischaPanch, best-practice vs feasible-practice in this space is still evolving....
But I wonder if it won't be possible (best practice?) to provide a set of Serena "Skill" files (see Beads example or others) that by convention work off a repo-pack file (say
serena.pack, produced by prompt, by standalone-script or by a repomix Skill.Skills are in Claude/Anthropic, and as a OpenCode plugin, and probably elsewhere.
Later, as Serena's polygot support improves, the serena.pack can house polygot content. But in the meantime you could still work on the small corner of TypeScript code in a repo that is 95% Python.
Thoughts?
MischaPanch commentedon Oct 26, 2025
Thanks for the input everyone. We are working on this and deciding on a strategy of how this feature will be published and which form exactly it will take. I'll let you know once more progress has been made on it. We (@opcode81 and I) realize that many users want to see this happen
MischaPanch commentedon Oct 29, 2025
Full monorepo support has now been merged, you just need to set the languages in your project.yml