I Love Monorepos–Except When They Are Annoying
1–3 of 3 posts
Re: I Love Monorepos–Except When They Are Annoying
#2Note: this is all about JS monorepos, and it looks like most complains are about kinds which "develop and publish multiple npm packages from a single git repository"
I am not a JS programmer, so all the monorepo complaints seem pretty alien to me. They don't really apply to C++/Python monorepos I am familiar with.
Re: I Love Monorepos–Except When They Are Annoying
#3Some lessons from monorepos:
Node Version Manager (nvm) with .nvmrc helps local conformance to a specific version of Node.js.
It's a chore to discover inter-repo dependencies, like utils/ depends on a/ and b/; it's a good thing to add to the docs.
`npm pack` with `file:/absolute/path/to.tgz` may be easier to reason about than linking. (Be sure to substitute with the real [or future] version before committing.)
After changing a common/ package, we have to merge one library, wait for it to publish, and then consume that new version in the next lib(s). So then the PRs have to happen in sequence and block other changes (or rebase accordingly).
If on Github, traversing to older commits (click Blame on package.json) really helps figure which version supported the older framework or dependencies you need to keep.