Package Maintainers: Separate Repos, Gitmodules, or Consolidated?


#1

HI all,
Any opinions on best practices for managing lots of packages in a track or a large project? Now that we got all of our testing patterns and refactoring tools worked out with StarryNight, I’m busy refactoring demo apps into packages and getting QA on them. Did like 20 packages in the past two days, with lots more in the works.

So now I’m starting to have packages everywhere, with duplicates of the same package in different demo apps; and I’m trying to figure out how best to manage and organize them. There seem to be three options:


Option 1
Each package gets it’s own repository, with ability to fork, github stars, branches, etc.

Option 2
Put all the packages in a single repository, similar to how the Meteor project itself is organized. Forking and github stars would be shared across packages.

Would probably organize this according to namespace, so there would be a ‘clinical’ repository, a ‘starrynight’ repository, an ‘active’ repository, etc. And within each one, there would be a dozen or more packages.

Option 3
Keep all the packages in their own repositories, but link them in a central repository via GItModules. Provides forking for individual packages, and stars for both the packages and tracks.


I’m leaning towards creating a repository for each namespace, and consolidating all the packages of a single namespace (following the example in meteor/meteor), and doing something similar for demo/reference apps, but linking them via gitmodules. Any thoughts or opinions on this?


#2

For reusable packages I would go for separate repository. For public packages I would use Atmosphere. For private ones https://www.npmjs.com/package/mgp. If you don’t have a Git repository limitation via GitHub plan (more repositories cost more money on GitHub), I would prefer a separate repository for each package. Then the Git log is focused. If you have a Git repository limitation, you could also put all private packages into one repository.
For packages that are specific to one app I would place them in the app repository in the packages folder.