Understanding Monorepos: What you need to know
Benjamin Cabanes & Philip Fulcher
Monorepos are hot right now, especially among Web developers. We’re here to help you understand what they are, what problems they solve, and how Nx makes them delightful. You can break down barriers and reclaim the collaboration you’ve been missing.
6. Why do companies use
monorepos?
• Manage complexity
• Organization-wide best
practices
• Maximizing shared code
• Consistency & predictability in
code
• Discoverability and
communication
• Foster collaboration
@PhilipJFulcher
@bencabanes powered by
14. You projects in the
same place
• High level view of projects
• Allows collaboration
• Removes assumptions
• Project discoverability
• Code reuse
• Architecture discoverability
@PhilipJFulcher
@bencabanes powered by
16. ✋ Monolith ≠ Monorepo ✋
@PhilipJFulcher
@bencabanes powered by
17. Monolith & Monorepo are different concepts
A monorepo is about code organization
A monolith is about code linking and particular type of deployment
@PhilipJFulcher
@bencabanes powered by
22. Cross-project changes
Architecture awareness
Relationships
are key
Performance with
smart commands
Project graph
Projects discoverability & always
up to date visual representation
Test/build only affected code
Identify relations & contracts
Smart code generation
Adds a smart layer to
project relationships
@PhilipJFulcher
@bencabanes powered by
28. A common situation
with polyrepos
Let’s share
some code!
@PhilipJFulcher
@bencabanes powered by
29. Sharing code with
polyrepos
4/ Write the shareable code
5/ CI & CD checks
6/ Deploy & publish to registry
1/ Create repository, setting
permissions, team management
2/ Setup CI & CD (waiting from
IT team)
3/ Setup tooling for build, serve,
lint …
@PhilipJFulcher
@bencabanes powered by
30. - Write the shared code
Sharing code with
monorepos
- Test consuming projects
directly from where you are.
All changes are done in a single PR
Consumers are all tested (high con
fi
dence)
No externals, faster merge and release
- Use existing code, tooling
@PhilipJFulcher
@bencabanes powered by
31. Sharing code with
polyrepos
- depends on published artefacts
- Changes, PRs, Code reviews, CI/
CD runs times “n” for each repo
- Takes time to complete and
start using the shared code.
@PhilipJFulcher
@bencabanes powered by
32. Sharing code with
polyrepos
A: v1.0
B: v1.0 C: v1.0
D: v1.0
A: v1.0
B: v1.0 C: v1.1
B: v1.0 C: v1.1
A: v1.0
B: v1.0 C: v1.1
D: v1.0 D: v1.1
😨
😎 😱
💎The Diam
on
d Dependency Problem 💎
@PhilipJFulcher
@bencabanes powered by
33. Polyrepos creates silos &
makes collaboration
harder.
@PhilipJFulcher
@bencabanes powered by
34. It is easy to do the wrong
things when working in
silos.
@PhilipJFulcher
@bencabanes powered by
41. One version of everything
03
Atomic commit across projects
02
No overhead to create new projects
01
Developer mobility
05
Consistent tooling
04
Monorepos
bene
fi
ts
@PhilipJFulcher
@bencabanes powered by
42. I can’t use a monorepo.
I do micro frontends. 😏
@PhilipJFulcher
@bencabanes powered by
48. Polyrepo
code ownership?
No high level overview
No structure
Everyone can depend on everything
Permissions per repository
@PhilipJFulcher
@bencabanes powered by
49. Monorepo
code ownership
High level overview
Visible structure & enforced by tooling
Clear hierarchy and dependencies
Granular access:
- constraints per import
- constraints per folder
- constraints per project
- custom constraints with tooling
@PhilipJFulcher
@bencabanes powered by