Version packages independently
maciej-gurban opened this issue · comments
Similar to the feature that Lerna offers, is independent versioning something that you'd consider supporting?
When versioning modules only for the purpose of using them in the same monorepo they reside in, it totally makes sense to keep the versions in sync. However, when you consider publishing the packages to the general public and the implications of using meaningul semver, this strategy brings more complications than benefits.
A breaking change in one package (or my root version), shouldn't mean a major version bump in all the packages - not unless they really had a breaking change. My guess would be that you're using oao to manage an actual application's monorepo rather than building a set components which can each be published independently. There are many use cases, mine included, where you might want to do the latter, or both, and I'm not sure keeping versions in sync really makes sense in that context.
Cheers!
I'm quite reluctant to add such a feature for several reasons:
- It would make oao quite complex.
- There's Lerna to support the wide variety of monorepo types out there. I would like oao to cater to the simpler use cases.
- In my experience, synchronous versioning (the only one supported in oao) is useful not only for application development (as you suggest in your post), but also for a combination of tools that are closely related together, live in the same monorepo and share similar development and publishing lifecycles (e.g. storyboard, Neutrino, etc.).
Which would be your use case, just out of curiosity?
I suppose I have a "two in one" use case. On one hand, we want to leverage a monorepo to develop our product and its components - responsibility of Team 1, but at the same time, Team 2 and Team 3 which cannot and will not become part of that monorepo also will need to use and contribute to these components.
Some of these components will be rather standalone and not tied to our application in ways other than having the same dependencies (on React, some UI lib and such). It's not such a big deal, but like I mentioned, unless we did a breaking change, we'd like to avoid marking the release as breaking - since it's not.
In our case, we also do pretty much total CI/CD, so we never really maintain any two versions of our applications. Master is the de facto state of production, and so having a root version in root package.json also doesn't make sense. It's different for each "component", since these can be used in other projects and will need to be versioned of course.
I realize that oao doesn't solve the "contribute to" part of the problem and we'll probably need to utilize Bit or something similar.
I can definitely understand your concerns about complexity. To make it work, there needs to be something to derive each package version from. Some solutions use commit messages for determining changes (I think Angular team follows such pattern), others require user input to determine to what version to bump each package. First requires a non-trivial change to developer workflow, second is more error prone and quite cumbersome for multiple packages.
Some food for thought after reading some Lerna issues:
There's an issue at lerna/lerna#961) which suggests to split publish and version commands. Having such functionality would mean that one could task developers or external packages to set appropriate versions in each package.json. These versions could be then used by the publish command to publish each package with "independent" version without overcomplicating things.
Does that sound better?
Still not tried lerna for my use case. I don't remember why im not using it, but there was something.
My use case. Im thinking for a long time to merge as many as possible of all of my 300 packages in one place, for lot of reasons.
Some are coupled, others not, some uses anothers because their are just libs. And most of them definitely cant be sync versioned.
Another important thing is that I rely on full automation: publishing+github releasing on ci, following conventional-commits (angular style, for years - started with standard-version, migrated to semantic-release and finally after creating dozen of tools and apps I end up with new-release+new-release github app) and need either separate changelogs or good looking releases page.
Following the conventional-commits style (conventionalcommits.com, eg angular), and wanting monorepo, I can do fix(foo-pkg): updates, which means that I should publish/release only foo-pkg (and others that were changed). Actually, looking ong the git status ot git diff, may be the way?
For the last couple of dayz im playing non stop with the standard-version, conventional-changelog-cli, conventional-recommended-bump and conventional-github-releaser.. but neither works. Tried dozen of different ways.
It's now possible to skip version bumps during publish (with the --no-bump flag). This goes in the line of what @maciej-gurban suggests: modify subpackage versions by manual means, or using other tools, and then run oao publish --no-bump to publish to the npm registry.
Just take into account that oao determines the packages to be published by looking and the git history and determining which ones have changed since the latest tag.
I guess this issue is now solved with the new approach — but feel free to reopen if needed.