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.
> 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.
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.
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.
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.
> 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.