3 ms·

Since we're doing an aside, what advantages do those "monorepo" things have over git submodules?

by Touche 8y ago

Benjamin_Dobell 8y ago
I don't maintain any monorepos, I've always used Git sub-modules; not just for Node.js, but for all sorts of stuff. However, I'm increasingly finding that sub-modules are a bit of a pain. If I patch a sub-module, I have to move into every single project that depends on the sub-module and pull the latest version. Additionally, if the sub-module is large it's a real waste of storage on my computer. That said, monorepos have annoyances of their own e.g. many modern package managers will happily check-out dependencies directly from Git. However, that's simply not going to work unless there's some standardisation in monorepo structure that the package manager is able to interpret.
nailer 8y ago
Excellent question! I use both regularly so are qualified to answer: - monorepo. Versioning over entire repo. node modules are used for granularity, separation of concerns, etc. - git submodules. Versioning over individual node modules. node modules are used for sharing code. Nothing stopping you from using both. Also, silly semi-technical point: I have never, ever, had a bad experience using git submodules, but many others have. I like submodules, but often work in teams where otherwise technically good people really hate them due to bad prior experiences.
dfabulich 8y ago
Here's a good article. https://danluu.com/monorepo/ https://danluu.com/monorepo/ It cites simplified organization, simplified dependencies, superior tooling, and easier cross-project changes. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne... is another good one. You can build issue/PR tools treating a monotree as containing multiple repositories; that's how Google and Facebook do their work (including checked-in OWNERS/MAINTAINERS files).
mnutt 8y ago
Monorepos are excellent if you have a group of related projects, especially if they depend on each other. Instead of opening a series of PRs for each project in a specific dependent order, you can open a single PR and move everything forward in lock-step, ensuring that every commit / tag has all projects in the monorepo working together. The biggest downsides are really around tooling: we've had tons of issues with our continuous integration environment (Travis CI) and build times trying to build only specific sub-projects using Lerna. The Github Pull Reviews and Issues pages can get pretty messy too, though we have a process to automatically add Github tags based on changes via Lerna. I suspect this is why bigger companies seem to be more successful with monorepos than smaller ones, because they have the resources to invest in building their own tooling.

Since we're doing an aside, what advantages do those "monorepo" things have over git submodules?

by Touche 8y ago

Since we're doing an aside, what advantages do those "monorepo" things have over git submodules?

I don't maintain any monorepos, I've always used Git sub-modules; not just for Node.js, but for all sorts of stuff. However, I'm increasingly finding that sub-modules are a bit of a pain. If I patch a sub-module, I have to move into every single project that depends on the sub-module and pull the latest version. Additionally, if the sub-module is large it's a real waste of storage on my computer. That said, monorepos have annoyances of their own e.g. many modern package managers will happily check-out dependencies directly from Git. However, that's simply not going to work unless there's some standardisation in monorepo structure that the package manager is able to interpret.

nailer 8y ago

Excellent question! I use both regularly so are qualified to answer: - monorepo. Versioning over entire repo. node modules are used for granularity, separation of concerns, etc. - git submodules. Versioning over individual node modules. node modules are used for sharing code. Nothing stopping you from using both. Also, silly semi-technical point: I have never, ever, had a bad experience using git submodules, but many others have. I like submodules, but often work in teams where otherwise technically good people really hate them due to bad prior experiences.

dfabulich 8y ago

Here's a good article. https://danluu.com/monorepo/ https://danluu.com/monorepo/ It cites simplified organization, simplified dependencies, superior tooling, and easier cross-project changes. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kerne... is another good one. You can build issue/PR tools treating a monotree as containing multiple repositories; that's how Google and Facebook do their work (including checked-in OWNERS/MAINTAINERS files).

mnutt 8y ago

Monorepos are excellent if you have a group of related projects, especially if they depend on each other. Instead of opening a series of PRs for each project in a specific dependent order, you can open a single PR and move everything forward in lock-step, ensuring that every commit / tag has all projects in the monorepo working together. The biggest downsides are really around tooling: we've had tons of issues with our continuous integration environment (Travis CI) and build times trying to build only specific sub-projects using Lerna. The Github Pull Reviews and Issues pages can get pretty messy too, though we have a process to automatically add Github tags based on changes via Lerna. I suspect this is why bigger companies seem to be more successful with monorepos than smaller ones, because they have the resources to invest in building their own tooling.