Hacker News Reader

Comment by raziel2p | Hacker News Reader

why does the package you want to split out need to remain part of the monorepo? in my mind, if you open-source packages, you should treat them just as you would external packages that aren't maintained by you - either install them with your langauge's package manager, use git submodules, or add init scripts that git clone them into the correct path (git-subrepo seems like it's facilitating this).

> Even if there are two public monorepos out in the open you can have similar problems trying to collaborate, because to modify one line of a package, you may need to pull a huge monorepo and its tooling down.

in my experience this has never really been a problem.

View on HN

what he said. The question is what are you trying to accomplish. are you just trying to make code dumps (i.e. no real development is done on the OSS side, just you'll dump code there that others can use) or is development supposed to take place on the OSS side.

if the former, its not really a Q, just figure out how to dump something that can be built independently of your mono repo and provide dumps.

If the latter, separate it out from your mono repo and treat it as any other external dependency you import it into your mono-repo. this obviously takes more work managing the new external repo, cutting releases and the like, but is more valuable to the community at large.

The goal is to allow development to happen on the OSS side. Unless you are a Google or Facebook with the ability to properly resource OSS, the 1st approach just leads to abandoned projects.

> this obviously takes more work managing the new external repo, cutting releases and the like, but is more valuable to the community at large.

I guess to gist of my question is how to keep the benefits of a monorepo while allowing a OSS development workflow.

It feels like OSS works best when there is a single Github repo that does not depend on a ton of other dependencies that change often.

as we said, presumably your mono repo imports external dependencies, right? its not all developed internally.

this just becomes another external dependency to be managed, albeit one you have more control of its actual release schedule

if this item depends on many other things that are also internal projects that you don't want to release, you will have to abstract them out and make the implementations pluggable with a working implementation that is part of the OSS side.

I’m very confused. Open sourcing makes it an independent project (might as well be external), and that’s necessary for the project to be of use to anyone else (Imagine one of your dependencies being part of someone else’s monorepo). In case that’s successful, you can handle it just like any other library dependency. (How do you do that in your monorepo?)

To elaborate... How can the community participate in the project if it is not a relatively independent project? If things are closely coupled to one person’s monorepo, then presumably the code is not usable for another person. So, for practical purposes, it might as well be just a code dump.

> why does the package you want to split out need to remain part of the monorepo

It becomes more difficult to maintain and you lose the advantages of a monorepo (atomic commits/branching, etc.)

Submodules doesn't work well with branching, and publishing to package manager now means you need to symlink.

It becomes quite painful quickly if the open-sourced dependency changes a lot.

Reply on news.ycombinator.com