Some lessons from monorepos:<p>Node Version Manager (nvm) with .nvmrc helps local conformance to a specific version of Node.js.<p>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.<p>`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.)<p>After changing a common/ package, we have to merge one library, <i>wait</i> 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).<p>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.
Note: 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"<p>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.