RFC: Monorepo conventions

[TheLarkInn]

For questions like this do we need to create a convention for a Monorepo version for the standards we have set up. If so, we should also add to webpack-contrib/webpack-defaults as an option for creation.

[TheLarkInn]

cc @webpack-contrib/admin-team

[joshwiens]

https://github.com/webpack-contrib/webpack-canary/issues/19#issuecomment-304065790

[valscion]

I have a feeling that I will need to have some sort of guidance if webpack-bundle-analyzer is to be moved to webpack-contrib (see #15) as I intended the next major version of webpack-bundle-analyzer to use a monorepo (see https://github.com/th0r/webpack-bundle-analyzer/pull/97).

The discussion in https://github.com/webpack-contrib/webpack-canary/issues/19 seems to have stalled, and I am also left wondering what I should anticipate to happen in the future once I get the webpack-defaults to control things in webpack-bundle-analyzer to be compatible with webpack-contrib.

[joshwiens]

Right out of the gate & per our previous discussion, accommodating a monorepo isn't going to be an issue, it's stalled mainly because to date there really hasn't been a need for it. Canary & it's possible mini-ecosystem tentatively being the first along with bundle analyzer.

That makes the issue more about what & when than if. Given that https://github.com/lerna/lerna seems to be the leader in the monorepo community, that would be my initial choice.

That would or course require an update to defaults & I have found that the most effective way to add major features to defaults is to p.o.c whatever it is in a live repo ( i.e. bundle-analyzer ) & once it's working, roll that back into defaults as a group of templates.

So, given you know what a repo looks like with defaults applied, if you implement lerna with that in mind there is no reason why I can't back port it into defaults & add a monorepo flag to the cli.

[valscion]

Sounds good to me! I've noticed that Lerna and yarn are a sweet match to handle a monorepo, as they complement each other with the help of yarn workspaces. I've noticed that you've just recently moved away from yarn, but in this case it is probably for the best to keep on using yarn

[joshwiens]

The yarn thing is another topic entirely. If we are going to use yarn again, it's going to be limited to the defaults flag that initializes & updates monorepos.

For the monorepo use case, yarn workspaces are a compelling enough reason to use it. For anything else, we are using NPM because while we are chained to Travis you are stuck with their lagging yarn version or installing a new own which kills and speed gains in the feedback cycle.

I'm seriously considering moving everything over to CircleCI and running custom build containers where we directly control the build time dependencies & versions but that's another topic entirely.

So, given bundle-analyzer is going to be our monorepo guinea pig, use lerna & feel free to use yarn if it improves the development experience for your team & the community.

[valscion]

So, given bundle-analyzer is going to be our monorepo guinea pig, use lerna & feel free to use yarn if it improves the development experience for your team & the community.

This will be interesting! Thanks for the support.

In https://github.com/webpack-contrib/webpack-canary/issues/19#issuecomment-304073861 you said the following:

If we are going to do it, go big with it not middle of the road.

Scope it as @webpack-canary/*, give it a chance to grow and allow it to be the single exception to the standardization rule with the intent that if adoption grows, it will become a standalone mini-ecosystem.

I will do the same with webpack bundle analyzer. I will scope the new packages as @webpack-bundle-analyzer/* to avoid future name conflicts. I've even got an npm organization setup already: https://www.npmjs.com/org/webpack-bundle-analyzer

[joshwiens]

That's fine. I'd love to scope webpack libs but that ship has long since sailed. No way to do it at this point where it wouldn't be incredibly disruptive to the community.

[michael-ciniawsky]

@TheLarkInn Is this still relevant ?

[michael-ciniawsky]

Closing for now, feel free to reopen if still relevant :)