Add flag --unlock-transitive to pub upgrade

[sigurdm]

pub upgrade x y z will only unlock x, y and z, but with the new flag pub upgrade --transitive x y z will unlock those packages and their transitive dependencies.

Same for --major-versions.

Fixes #3504

We could also consider making this the default behavior - it is most likely what people expect.

[jonasfj]

This is a bit confusing, because:

• pub upgrade and pub upgrade --transitive are the same thing.
• pub upgrade foo and pub upgrade --transitive foo are NOT the same thing.

[sigurdm]

pub upgrade and pub upgrade --transitive are the same thing.

Well, pub upgrade in my mind means pub upgrade <all dependencies> and the transitive closure of <all dependendencies> is still <all dependencies>.

So it is the same rule we apply.

But we could disallow --transitive when there are no given deps to update.

[sigurdm]

Let's call it --unlock-transitive.

[sigurdm]

This will not work in cases where the latest version of the upgraded package has more dependencies than the current.

Then they will not be unlocked.

Say:

foo 1.0.0 has

dependencies:
  # no dependencies

foo 1.5.0 has

dependencies:
  bar: ^1.0.0

And the main pubspec.yaml looks like

dependencies:
  foo: ^1.0.0
  bar: ^1.0.0 # bar will not be unlocked by `pub upgrade foo --unlock-transitive`

We have agreed that is a relatively rare case, and we can live with it.

[jonasfj]

Please add the negatable: false, if we want the negatable variant I think we should call it --lock-transitive rather than --nounlock-transitive 🤣

[jonasfj]

Suggested change

	argParser.addFlag(
	'unlock-transitive',
	help: 'Also upgrades the transitive dependencies '
	'of the listed [dependencies]',
	);
	argParser.addFlag(
	'unlock-transitive',
	help: 'Also upgrades the transitive dependencies '
	'of the listed [dependencies]',
	negatable: false,
	);

[jonasfj]

Suggested change

	--[no-]transitive Also upgrades the transitive dependencies of the listed [dependencies]
	--transitive Also upgrades the transitive dependencies of the listed [dependencies]

[sigurdm]

Please add the negatable: false, if we want the negatable variant I think we should call it --lock-transitive rather than --nounlock-transitive 🤣

I disagree. The negations are useful if we ever change the default. And in that case they should also be present from the beginning.

I think --no-unlock-transitive reads ok for a very rarely used option. (And we are specifically asking pub to not unlock the transitive dependencies. Not to lock them.

[sigurdm]

Seems like I merged this by accident...

Will revert.