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:
Each package gets it’s own repository, with ability to fork, github stars, branches, etc.
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.
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?