Split packages each into its own repository

[mitar]

This repository still contains multiple packages. Would it be better to really split each one into a separate repository?

Especially with NPM, to my knowledge, this would allow one to easily depend with a package on the forked git repository.

[stubailo]

Hmm there are definitely pros and cons. There are also disadvantages to having a ton of separate repositories. In fact the limitation of NPM in installing packages from git is about the only advantage I can think of - are there others?

[mitar]

You cannot include it as a git submodule. If I try to include this repository into packages inside my Meteor app, it will not work.

[mitar]

I think multiple repositories can be solved easily by using some common prefix, or a new GitHub organization.

[mitar]

https://github.com/meteor-package/blaze sounds pretty cool.

[stubailo]

Yeah the organization approach would make the most sense if it were split up.

[martijnwalraven]

I think the biggest downside of one package per repository is that you may want to keep GitHub issues and pull requests for closely related packages together.

[stubailo]

I think once Zube.io creates a multi-repository view, it could be less of an issue - we could just use that to manage issues across repos.

[mitar]

Also, we could have a main repository for issues, and all other repositories could have issues closed. So all issues are in the same place, and is like a landing project (maybe without even having the code by itself). Which then links to all other repositories and so on.

[mitar]

(If we are talking about meteor-package organization.)

[mitar]

Related: npm/npm#2974

[martijnwalraven]

This also seems relevant, if we are prepared to engage in improving NPM:

To be clear, monorepo support is not something that's on the CLI team's roadmap for the next 6-12 months. I'm interested in seeing better support for it within the CLI, but the team isn't going to have the time and attention to do it ourselves. For that reason, specific proposals (perhaps in the form of (prototype) code) are going to be more useful than generic requests for improved monorepo support.

[mitar]

Should we try to contribute to NPM this feature then?

[laosb]

I've prepared an organization for meteor packages -- ourmeteor. I've also taken the ourmeteor.com for further use. If you have any suggestions on OurMeteor, let it happen on ourmeteor/discussions.
Here're my cents of OurMeteor.

[mitar]

I am moving this issue to a later milestone. For now we are going with Meteor-only packages.

[stubailo]

If we want to go with an NPM monorepo, the Babel folks have this cool project that they use to manage a ton of packages. Might be worth looking at later: https://lernajs.io/

[mitar]

Let's close this for now and keep it monorepo.