Management for collections of packages across teams
For the increasingly common scenario where teams need to work on more
than one npm
package at a time, mondorepo
enables collaboration on
a collection of jointly developed repositories that may contain one or
multiple projects themselves.
One project, multiple packages and repositories, all aware of each other at runtime.
The Node.js package ecosystem has been traditionally developed following the one package per repository rule:
What is a package?
A package is any of the following:
a) a folder containing a program described by a package.json file
...
g) a git url that, when cloned, results in (a).
This is workable for developing packages that are small in size or complexity and live in relative isolation. As projects' scale increases this approach has a couple significant problems.
- The amount of code in a complex project often increases beyond what would ideally live in a single package.
- Most times, multiple teams of developers need to collaborate on concurrently developed packages managed in separate repositories.
Traditional approaches to solve these problems are:
- Use relative paths across a huge codebase
- Include jointly developed packages inside the main project's
node_modules
directory. - Following the
monorepo
approach (mono
notmondo
).
While there are potential advantages to each of these approaches, here at Sencha we decided to tackle the problem in a way that projects remain modular and sub packages can be developed on their own.
We call these mondorepos
.
As an alternative to monolithic repositories, mondorepo
enables teams to collaborate
on big complex projects that span across multiple repositories. Each subpackage can be a
mondorepo
on its own and so on.
An example of this project structure would look like this:
Repository: 'awesomecorp/MyAwesomeProject'
MyAwesomeProject/
index.js
package.json // <- contains a reference to "awesomecorp/My-pkg" under "mondo.uses.My-pkg"
Repository: 'awesomecorp/My-pkg'
MyAwesomeProject/
index.js
package.json
Running mondo install
will connect all used repositories (declared inside mondo.uses
) and make My-pkg
available to be used on a simple require('My-pkg')
statement, isn't that neat?
This effectively means that each subpackage can be developed on its own if needed, but also can be included as part of any other project that wants to jointly develop a bunch of its own requirements.
We prefer yarn
but npm
is also fine:
$ yarn global add mondorepo
Once you checked out a project that uses mondorepo
, just run:
$ mondo install
If you have a set of known forks configured and wish to use them when installing the project, run:
$ mondo install --forks
For help on how to use the CLI tool run:
$ mondo help
For help configuring your project as a mondorepo
, check our Getting started guide.
Please read CONTRIBUTING.md for details on the code of conduct, and the process for submitting pull requests.
mondorepo
uses SemVer for versioning. For the versions available, see the
tags on this repository.
This project is licensed under the MIT License - see the LICENSE file for details