Bumping dependencies on publish about oao HOT 25 CLOSED

I think instead of --bump-dependent-reqs <exact|no> it might be more straightforward to use something like --no-bump-dependents and --bump-exact? There's something about the terminology in the proposed flag that doesn't sit well, separate flags make more sense imo here. But in the end I'm partial to either solution, I'll probably stick with bumping in range anyhow 😝

from oao.

Okay I see, I'm not really sure this has to be done in a particular order, as long as the version is updated at publish time.

It could also change the list of package to publish; If the version needs to be updated; the package needs to be published.

I would see it working this way:

• Find changed repositories (personally I would be fan of a --all option to publish all packages everytime, but that's for another issue/PR :) ) add them to the list of repositories to publish
• Find repositories that depend on others and add them as well to the list
• Ask for new version (or take from CLI args)
• Apply version everywhere, including dependencies
• commit/push if needed (!--no-git-commit)
• publish if needed (!--no-publish)

from oao.

Could it also be a value instead of different options ?

@onigoetz Certainly! I prefer in this case --bump-dependent-reqs= 'range' | 'exact' | 'no' (default: range). The other options refer to dependent-versions, but I find that misleading. It's not the versions of dependent packages that we're modifying, but their version requirements.

I feel like it'd be smarter to do this implicitly, setting the version on publish could tell whether it's range or exact?
--new-version ^x.y.z would mean we're bumping with a range, --new-version x.y.z

Asking the user to introduce the carot in --new-version for what we consider default behaviour is a bit strange. If the user doesn't read this, she'd have --new-version x.y.z meaning "use exact versioning for dependent reqs" and --increment-version-by major meaning "use range versioning for dependent reqs". It looks confusing to me.

I would not couple how the user sets the new version to how oao bumps package requirements. It may save a few keystrokes, but makes the UX a bit more cryptic, in my opinion. Here are some examples how I would see it:

• oao publish (default [opinionated] behaviour, bumps all subpackages to the version set by the user interactively + bumps dependent reqs + publishes all)
• oao publish --bump-dependent-reqs exact or no (same, but with a different configuration for dependent reqs)
• oao publish --new-version x.y.z (no need to prompt + dependent reqs using ranges)
• oao publish --new-version x.y.z --bump-dependent-reqs exact or no (same, but using exact dependent reqs)
• oao publish --increment-version-by major (no need to prompt + dependent reqs using ranges)
• oao publish --increment-version-by major --bump-dependent-reqs exact or no (no need to prompt + exact dependent reqs)
• oao publish --no-bump (doesn't touch versions nor dependent reqs)

from oao.

I made a tiny package that does just this to quickly solve my needs as I'm not sure this is something you want to support.
@guigrpa, if it's something you think fits in oao I'll port it :)
https://github.com/jeroenptrs/bump-siblings

from oao.

Hi,

I'd definitely be interested in this as well, I'm looking for a lightweight alternative to Lerna (which had this feature) and it would be a showstopper to not have it :/

from oao.

Right now I run my package under the postpublish script in package.json (which gets auto triggered when you publish a package).

The only issue I still have is that the actual bumping (with npm publish) also commits before any of the changes, so the actual bumping of packages is left unstaged. You could run oao publish with the --no-git-commit flag and then commit everything in one go (or like I did, force push and re-set the tag)

from oao.

So it's only accurate on the next release ?

If I have a package a:1.0.0 that depends to b:1.0.0 If I publish version 1.1.0 then a:1.1.0 will depend on b:1.0.0, right ?
Shouldn't that change be done pre-publish ?

from oao.

This issue and #101 really go hand in hand -- but a PR for that issue is already up at #102. The way you want this to happen is to follow the reverse dependency tree. So that b (the package a depends on) gets published first. Then the postpublish hook kicks in, bumping the version of b in a, and then a gets published. This is obviously not a use case when a and b depend on each other, but I'm not a fan of organizing my packages that way.

What I'm hinting at is that oao runs npm version first which bumps the version of each package and then commits that change. It's just a bit of manual work but if you want to commit all changes in one go you could run oao publish --no-git-commit (with the bump-siblings package as a postpublish hook in all packages that are a dependency in others) and commit it all together yourself. It's obviously a bit hacked together for the sake of proof for this issue but it does work :)

note: I mistakenly said npm publish in my previous comment, but it's npm version then npm publish per package.

from oao.

I agree that (sub)dependency checking should happen at a more sensible step. Ideally this should all be part of prepublish checks!

from oao.

personally I would be fan of a --all option to publish all packages everytime, but that's for another issue/PR

I guess you could say that's how it is now, by default

from oao.

I guess you could say that's how it is now, by default

I'm confused, it publishes all packages everytime ?
If yes then why do the check of changes since last release ?

If it's the default that's great anyway :)

from oao.

Thanks for all the interesting contributions.

I've also been bitten by oao's not bumping cross-dependency versions, which generates some hard-to-find bugs later on.

In fact, in order to simplify oao publish (there are already other more complex tools out there when you need a lot of bells and whistles), we could:

1. Publish in reverse-dependency order by default (i.e. no need to specify --tree — see #102)
2. Always publish all dependencies, with the version number specified by the user. One of oao's premises is that subpackage versions are synchronised, so this would make the tool more predictable
3. Before publishing as version x.y.z, always bump all internal dependencies (among subpackages in the monorepo) to ^x.y.z

At least 2 and 3 would be breaking changes. But I think the API surface is reduced, the tool becomes simpler and more predictable (and more maintainable as well 😀).

from oao.

1. I don't know the exact implication of doing or not doing it
2. I totally agree with it, that's what I do in my projects anyway.
3. I'd give the option to use range or exact, could be open to the user. the default could be the range since that's what is more common in the ecosystem it seems.

And yes a simpler and more predictable tool is exactly what I'm looking for coming from Lerna :) (no hate on Lerna, it's a great tool as well :) )

from oao.

I think 1 is also how lerna does it by default, since you'd want to start your workflow at the leaves and build your way up. @guigrpa if you wan't I'll do this in my PR :)

from oao.

As far as the rest I'm ok with that. Especially 2) is how I do it now at the moment too !

from oao.

@jeroenptrs Yes, please set the reverse-dependency order as default (removing the flag). Thanks!

from oao.

I can modify my PR ( #104 ) to always take all packages and change all their dependencies, this would solve 2) and 3)

from oao.

@onigoetz That's very helpful, thanks! I guess the new approach would remove most of the complexity in the PR, right? For instance determining which subpackages are dirty or not — all are considered dirty.

Regarding your suggestion on how to modify dependent versions, we could have: 1) --update-dependent-versions (with a range, ^x.y.z — default), 2) --update-dependent-versions-exact (with the new monorepo version, x.y.z), and 3) --no-update-dependent-versions.

from oao.

The flag names are still a bit confusing to me. What would we call this operation? Bumping dependent requirements maybe? Then maybe the most appropriate names could be: --bump-dependent-reqs, --bump-dependent-reqs-exact, --no-bump-dependent-reqs.

from oao.

Yes it would indeed remove much of its complexity :)

Could it also be a value instead of different options ?

1. --update-dependent-versions= "range" | "exact" | "no" (with range being the default)
2. --bump-dependent-reqs= "range" | "exact" | "no"
3. --bump-dependent-versions= "range" | "exact" | "no"

from oao.

I feel like it'd be smarter to do this implicitly, setting the version on publish could tell whether it's range or exact?
--new-version ^x.y.z would mean we're bumping with a range, --new-version x.y.z would mean we're bumping to an exact version. And if you want users to explicitly state dependencies shouldn't be bumped in that case you can add a flag --no-dependents

from oao.

@jeroenptrs that wouldn't work if the version is requested by the CLI instead of provided as an argument

from oao.

@onigoetz It would indeed not work on --increment-version-by as we have it right now, but I think we can make it work.

a) As seen here: https://github.com/guigrpa/oao/blob/master/src/publish.js#L94..L97 the next version is taken either from prompt or cli commands. But both the prompt and --new-version could already take interpret an implication with minimal changes (just looking for tilde or carot -> range, else exact).
b) I feel like we're mostly adding flags to override default behaviour, so I'd say the value that comes out of --increment-version-by could just follow default behaviour (use range and do update dependents) and if the user wants to override you can use flags like --no-dependents and --exact.

a - edit) as suggested in b) we can also always imply a range and override with exact.

This seems the most straightforward approach in terms of UX, especially since oao is already opinionated I don't see any harm in doing it this way. What do you think? @onigoetz @guigrpa

from oao.

Okay, I updated my pull request on #104

from oao.

This has shipped in v2.0.0. Please let me know if you find any issues!

Thanks for all the ideas and work put behind this issue and related PRs.

from oao.