Add "latest" flag to "yarn upgrade" #3510

rally25rs · 2017-05-26T14:57:10Z

Implements requested feature in #3384

Adds a yarn upgrade [--latest/-L] flag.

This flag instructs Yarn to upgrade all dependencies to the latest version specified by it's registry, ignoring the versions specified in package.json.

This is functionally equivalent to running yarn upgrade <package> and passing all dependency names (yarn upgrade foo bar baz ...etc).

Test plan

In test file __tests__/commands/upgrade.js :

Added additional tests for the existing yarn upgrade behaviors.
Added tests for behavior specific to latest flag.

Documentation

PR for the website documentation repo should be merged at the same time:
yarnpkg/website#513

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

arcanis · 2017-06-02T13:08:08Z

This is functionally equivalent to running yarn upgrade and passing all dependency names (yarn upgrade foo bar baz ...etc).

Shouldn't this flag be called --all, then?

rally25rs · 2017-06-02T13:21:09Z

I've always found this to be the most confusing part of Yarn;

I always expect yarn upgrade to be the same as yarn upgrade <all packages> but it isn't.

If you specify a package name, it ignores the version range in package.json.
If you don't specify a package name, then it uses the version ranges in package.json.

I think --latest is more indicative of what it's doing:

yarn upgrade - upgrades all respecting version range in package.json
yarn upgrade --latest - upgrades all to latest, ignoring package.json

In other words, yarn upgrade itself is already a "--all" in that it upgrades all packages. This change is really about what version it upgrades all packages to.

... hope that makes sense. It's early and I'm on my 1st cup ☕️
There is additional discussion in issue 3384 (linked in the original PR comment)

cpojer · 2017-06-07T14:06:36Z

I like --latest, I think the explanation makes sense.

cpojer · 2017-06-07T14:11:25Z

src/cli/commands/upgrade.js

+    addArgs = Object.keys(allDependencies)
+      .map(dependency => {
+        return getDependency(allDependencies, dependency);
+      });


nit: you don't need the curly braces and the return here.

cpojer · 2017-06-07T14:11:45Z

src/cli/commands/upgrade.js

@@ -11,6 +11,7 @@ export function setFlags(commander: Object) {
  // TODO: support some flags that install command has
  commander.usage('upgrade [flags]');
  commander.option('-S, --scope <scope>', 'upgrade packages under the specified scope');
+  commander.option('-L, --latest', 'upgrade packages to the latest version, ignoring version ranges in package.json');


do we really need the -L shorthand? Let's just go with --latest.

OK, was just following the convention of the other flags. I'll remove that -L.

cpojer · 2017-06-07T14:11:59Z

Would you mind rebasing this diff and making it pass on CI? :)

rally25rs · 2017-06-07T15:30:52Z

oops, I made the classic mistake of git commit -a and forgetting to git add new files 😢
Merged latest master into the branch and fixed tests. Should be good to go now @cpojer

arcanis · 2017-06-07T16:54:50Z

__tests__/commands/upgrade.js

+    expect(lockEntryIndex).toEqual(0);
+    expect(lockfile.indexOf('left-pad@<=1.1.1:')).toEqual(-1);
+    expect(lockfile[lockEntryIndex + 1]).toContain('1.1.3');
+    expect(pkg.dependencies).toEqual({'left-pad': '^1.1.3'});


You shouldn't use left-pad for this test, otherwise it will break if they release a new version. I think you can use yarn-test (cc @kittens ?)

Hmm, I actually thought the packages used during tests were all loaded from the 'offline mirror' directory of __tests__/fixtures/request-cache/... but it does like like just the left-pad tgz files are in there, not the metadata. So all these tests are actually resolving real metadata? that seems fragile...

I needed a package that had enough diverse version numbers to cover all these upgrade cases, and left-pad was the first one I found that worked.

Is there someplace I can see what version of yarn-test exist?

(side-note, it might be useful to document how these tests actually work and should be constructed, for new developers who want to contribute. It took me a while the first time I needed to add one.)

So all these tests are actually resolving real metadata? that seems fragile...

Think so. That's why our tests practically never completely pass: we always end up timeouting at least one of them 😞 Probably should fix this at some point! I thought maybe we could set up some sort of fake registry with only the few endpoints required, that would extract its data from a repository local folder.

We can discuss this in #3455

The metadata for left-pad is taken from the __tests__/fixtures/request-cache/ directory, so a new version pushed to the live registry would not break the test. These tests actually pass with no internet connection.

arcanis · 2017-06-07T16:57:28Z

__tests__/commands/upgrade.js

+
+    expect(lockEntryIndex).toEqual(0);
+    expect(lockfile[lockEntryIndex + 1]).toContain('1.1.3');
+    expect(pkg.dependencies).toEqual({'left-pad': '~1.1.2'});


You can use left-pad here, but then use ~1.0.1 (should resolve to 1.0.2) instead of ~1.1.2, since we know there won't be any more release to this branch, which is not the case for 1.1.x.

arcanis · 2017-06-07T16:59:15Z

__tests__/commands/upgrade.js

+    expect(lockfile.indexOf('left-pad@<=1.1.1:')).toEqual(-1);
+    expect(lockfile[lockEntryIndex + 1]).toContain('1.1.3');
+    expect(pkg.dependencies).toEqual({'left-pad': '^1.1.3'});
+  });


This doesn't feel right ... shouldn't we have to pass the --latest flag to have this behavior? It contradicts the "no argument means all packages" behavior ("upgrades to latest matching package.json semver when no package name passed").

This test actually passes in current Yarn without my modifications (in other words, this is how Yarn has worked for a while). This is testing the command yarn upgrade left-pad, which is roughly equivalent to yarn add left-pad. The add command resolves to the passed in version range for left-pad which is unspecified, so it resolves to latest.

There is some discussion around that confusing behavior in 3384 3266 3204
I've always sort of wondered if it's an unintentional behavior.

I just re-read my comment and decided it's confusing... In clearer terms, the way Yarn 0.24 - 0.26 all work currently is that if your package.json is:

"dependencies": { "left-pad": "^1.0.0"

Then yarn upgrade will upgrade left-pad to the greatest match for ^1.0.0.
However yarn upgrade left-pad will upgrade to latest.

I didn't change that behavior.
This PR just adds the option to:

yarn upgrade --latest which will upgrade left-pad to latest (ignoring what was in package.json)

There is currently, and with this PR, still no way to yarn upgrade <package_name> and have it use the range specified in package.json, unless you manually copy-paste the range yourself and do yarn upgrade left-pad@^1.0.0

Yep, you're right. I feel like this should be considered as a bug ... otherwise there's no way to upgrade a specific package inside its allowed boundaries :/ can you open a separate PR where we could discuss this?

I spawned #3603 as a discussion issue and added you as an assignee.

cpojer · 2017-06-07T17:00:50Z

Oops, that was within the same 15 seconds! @rally25rs would you mind sending a follow-up PR to fix the issues that @arcanis pointed out?

develar · 2017-06-08T10:27:38Z

One problem with this flag — range specifier is not preserved:

"electron-osx-sign": "0.4.6"

changed after yarn upgrade --latest to

"electron-osx-sign": "^0.4.6"

i.e. package not upgraded, but range specifier changed.

Range specifier must be preserved.

arcanis · 2017-06-08T12:44:19Z

@develar good remark, can you open an issue?

develar · 2017-06-08T12:50:30Z

Filed #3609 .

rally25rs · 2017-06-08T12:52:57Z

@develar @arcanis There is at least one issue already open for this same thing against upgrade-interactive #2367

Perhaps we can just combine them (I believe that from a code perspective, they are the same issue)

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

rally25rs added 2 commits May 26, 2017 09:43

Added additional (passing) tests for existing upgrade behavior

02e0477

[yarnpkg#3384] add --latest/-L flag to

c48806c

rally25rs added a commit to rally25rs/website that referenced this pull request May 26, 2017

Upgrade docs to add yarn upgrade --latest flag

b9bdd28

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

rally25rs mentioned this pull request May 26, 2017

Upgrade docs to add yarn upgrade --latest flag yarnpkg/website#513

Merged

rally25rs mentioned this pull request Jun 5, 2017

[question] Why do yarn upgrade [package] and yarn upgrade choose different package versions? #3016

Closed

cpojer reviewed Jun 7, 2017

View reviewed changes

rally25rs added 2 commits June 7, 2017 11:15

merged master to branch upgrade-latest-parameter-3384

89fa8d4

added previously forgotten files to make tests actually pass

5d79e03

arcanis requested changes Jun 7, 2017

View reviewed changes

cpojer merged commit b9fe983 into yarnpkg:master Jun 7, 2017

rally25rs mentioned this pull request Jun 7, 2017

(discussion) upgrade vs upgrade [package] version inconsistency #3603

Closed

develar mentioned this pull request Jun 8, 2017

yarn upgrade --latest doesn't preserve range specifier #3609

Closed

rally25rs deleted the upgrade-latest-parameter-3384 branch June 8, 2017 13:01

bestander pushed a commit to yarnpkg/website that referenced this pull request Jun 15, 2017

Upgrade docs to add yarn upgrade --latest flag (#513)

c0582c8

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

lovelypuppy0607 added a commit to lovelypuppy0607/website that referenced this pull request May 11, 2023

Upgrade docs to add yarn upgrade --latest flag (#513)

d95e0f9

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

Kumljevx1 added a commit to Kumljevx1/yarn-website that referenced this pull request Aug 26, 2024

Upgrade docs to add yarn upgrade --latest flag (#513)

156ea0a

This is the documentation change that corresponds to yarnpkg/yarn#3510 They should be merged at the same time.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add "latest" flag to "yarn upgrade" #3510

Add "latest" flag to "yarn upgrade" #3510

rally25rs commented May 26, 2017 •

edited

Loading

arcanis commented Jun 2, 2017

rally25rs commented Jun 2, 2017 •

edited

Loading

cpojer commented Jun 7, 2017

cpojer Jun 7, 2017

cpojer Jun 7, 2017

rally25rs Jun 7, 2017

cpojer commented Jun 7, 2017

rally25rs commented Jun 7, 2017

arcanis Jun 7, 2017

rally25rs Jun 7, 2017

arcanis Jun 7, 2017

rally25rs Jun 7, 2017

rally25rs Jun 8, 2017

arcanis Jun 7, 2017

arcanis Jun 7, 2017

rally25rs Jun 7, 2017

rally25rs Jun 7, 2017

arcanis Jun 7, 2017 •

edited

Loading

rally25rs Jun 7, 2017

cpojer commented Jun 7, 2017

develar commented Jun 8, 2017 •

edited

Loading

arcanis commented Jun 8, 2017

develar commented Jun 8, 2017

rally25rs commented Jun 8, 2017

Add "latest" flag to "yarn upgrade" #3510

Add "latest" flag to "yarn upgrade" #3510

Conversation

rally25rs commented May 26, 2017 • edited Loading

arcanis commented Jun 2, 2017

rally25rs commented Jun 2, 2017 • edited Loading

cpojer commented Jun 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cpojer commented Jun 7, 2017

rally25rs commented Jun 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arcanis Jun 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cpojer commented Jun 7, 2017

develar commented Jun 8, 2017 • edited Loading

arcanis commented Jun 8, 2017

develar commented Jun 8, 2017

rally25rs commented Jun 8, 2017

rally25rs commented May 26, 2017 •

edited

Loading

rally25rs commented Jun 2, 2017 •

edited

Loading

arcanis Jun 7, 2017 •

edited

Loading

develar commented Jun 8, 2017 •

edited

Loading