yarn upgrade [pkg@tag] does not upgrade dist-tag version

[sambernet]

Do you want to request a feature or report a bug?
bug

What is the current behavior?

When using a dist-tag dependency in the package.json, (example using kw-util@bump), yarn add will install the version the tag currently points to and add it to yarn.lock.

Now when a new version is published to the repo and the tag is updated to point to the new version, yarn outdated <package-name> will correctly reflect that and show the new dependency:

yarn outdated v0.20.3
Package Current                       Wanted                        Latest Package Type    URL
kw-util 1.3.2-dev.20170227105448      1.3.2-dev.20170227113905      1.3.1  devDependencies
Done in 4.25s.

Note that the package.json did not change here, only the dist-tag in the repo moved to a new version.
Running yarn upgrade [package@tag] now does NOT upgrade the package to the new version:

yarn upgrade kw-util@bump
yarn upgrade v0.20.3
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved 0 new dependencies.
Done in 22.37s.

Yarn outdated still gives the same output:

yarn outdated v0.20.3
Package Current                       Wanted                        Latest Package Type    URL
kw-util 1.3.2-dev.20170227105448      1.3.2-dev.20170227113905      1.3.1  devDependencies
Done in 4.25s.

Note: there is a range of other open issues about install picking the wrong versions for dist-tags, including implicit latest tag, e.g. #2648, #1690, #2154.

Note 2: running yarn upgrade (all packages) will indeed upgrade the package to the version the tag is pointing to - but since our use case is about updating upstream internal modules, we need to be able to do this for individual packages, without having to upgrade external/public packages.

Ideally it should be possible to provide a list of packages to upgrade, too (we currently have 17 internal modules, which need to be upgraded after every upstream build...). The CLI actually accepts that, but since it doesn't work and the documentation only mentions a single package (see https://yarnpkg.com/en/docs/cli/upgrade#toc-yarn-upgrade-package-tag), I'm not sure if the CLI is lazy or actually supports upgrading several named packages in one go.

If the current behavior is a bug, please provide the steps to reproduce.
failure requires publishing a new version for an existing dist-tag, so no simple test-case possible.

What is the expected behavior?
upgrade package version to the version currently being pointed to by a dist-tag, when running yarn upgrade [package@tag]

Please mention your node.js, yarn and operating system version.

• node.js: 7.6.0
• yarn v0.20.3
• Win 10 Pro x64 1607

[rally25rs]

Does anyone have a setup where they can easily retest this on Yarn 1.2.1? If not, I can publish a dummy package to NPM and unpublish it later, just wanted to avoid adding a garbage package to NPM...

[sambernet]

Easily might be the wrong term (need to republish new package versions) - but can probably test this tonight with our private repo.

[Hypnosphi]

Checked it in private repo — dependency is updated correctly, but package.json stays untouched. Is it intended?

[rally25rs]

@Hypnosphi yes the current implementation of upgrade leaves package.json unchanged, only yarn.lock is updated. There is some discussion in another issue on whether or not we should update package.json as well, but for now that is the intended behavior.

Any objections to closing this issue?

[sambernet]

Quite late to the party, but I can confirm this works as expected now. Yarn now also supports the --pattern and (semantically even better) @scope/ parameters to yarn upgrade which makes this quite a flexible and powerful thing 👍

Unfortunately our NPM workflow can still not be built with yarn as we're now affected by #4632 😢
That issue shows that other than stated above by @rally25rs the package.json is indeed updated, and the tag is changed to the actual version the tag resolves to at the time of upgrade. While this might have been the behavior at the time of writing, now for yarn v1.3.2 it's unfortunately not.