[Bug?]: `yarn version prerelease` not working properly under `v3.1.1`

jiqiang90 commented 2 years ago

Self-service

[ ] I'd be willing to implement a fix

Describe the bug

Hi we recently upgrade from yarn v2 to v3, and we found the yarn version prerelease is not working, as the the suffix suppose be increased, please see below.

To reproduce

yarn version prerelease

This will work : tested from a patch release to prerelease, for example from 0.25.4 to 0.25.5-0, works fine.
This failed: from a prerelease version to prerelease, the suffix is not increase. We expect from 0.25.5-0 to 0.25.5-1, but this version remain unchanged
Update: I found actually we have stableVersion defined in package.json, it will take it as latest prerelease version and increase the suffix. For example we have stableVersion is 0.25.5.-0, and version is 0.25.5-3, after run yarn version prerelease, the version will be replaced by 0.25.5-1 (down from 0.25.5-3 ? ), seems is not the right behaviour to us.

Environment

OS: MacOS 10.14.6
Node version: v16.13.1
Yarn version: 3.1.1

Additional context

No response

AlCalzone commented 2 years ago

This also happens when specifying an exact version. E.g. with

version: 1.3.0-beta.0
stableVersion: 1.2.3

running yarn version 1.3.0-beta.1 actually changes the version to 1.2.4-0 instead.

Edit: It looks like yarn version 1.3.0-beta.1 --deferred computes the bump based on the version field (in this example, resulting in "prerelease"), but then yarn version apply applies it to the stableVersion and not the version, resulting in a different bump than intended.

I might be mistaken here, but either this line https://github.com/yarnpkg/berry/blob/ce1e0c31781e3fc791cfa86a01348c4f0dba9aec/packages/plugin-version/sources/commands/version.ts#L69 should not suggest a strategy if the version and stableVersion field are not the same or this assumption https://github.com/yarnpkg/berry/blob/ce1e0c31781e3fc791cfa86a01348c4f0dba9aec/packages/plugin-version/sources/versionUtils.ts#L100-L103 is not correct.

yarnbot commented 2 years ago

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

AlCalzone commented 2 years ago

@arcanis there is a workaround for this and a good guess what causes the issue. I'm not sure how to reproduce this with sherlock though.

vecerek commented 2 years ago

This is very annoying, especially on large monorepos and it's happening on yarn v3.2.0 as well 🙁

samijaber commented 2 years ago

Confirming that I have encountered this issue as well for https://github.com/BuilderIO/mitosis .

In my case:

my package has stableVersion: 0.0.13-2 and version: 0.0.13-3.

I run yarn version prerelease:

➤ YN0000: @builder.io/mitosis-cli@workspace:packages/cli: Bumped to 0.0.13-3

There is zero documentation around stableVersion, which makes it unclear what is creating it, or how we can adequately manipulate it to get the correct behaviour.

AlCalzone commented 2 years ago

FWIW, deleting stableVersion from package.json before and after bumping the versions does result in the expected behavior. https://github.com/AlCalzone/release-script/pull/109/files

samijaber commented 2 years ago

Sherlock Reproduction

I tried to Copy as Markdown Issue and Report issue on GitHub, but both outputs were broken for me ("404 Not Found"). I opted for the Copy as Markdown Link with Preview and Output output

Playground

const {promises: {readFile}} = require(`fs`);

await packageJsonAndInstall({
version: "0.0.1",
});

// Run `yarn version prerelease` for the first time.
// This will create the `stableVersion` key
await yarn(`version`, `prerelease`);
const pkgJson = JSON.parse(await readFile(`package.json`, `utf8`));
expect(pkgJson.version).toBe('0.0.2-0')
expect(pkgJson.stableVersion).toBe('0.0.1')

// Run `yarn version prerelase` with `stableVersion` present.
// This is where the bug occurs.
await yarn(`version`, `prerelease`);
const pkgJson2 = JSON.parse(await readFile(`package.json`, `utf8`));
expect(pkgJson2.version).toBe('0.0.2-1')

Output:

Error: [2mexpect([22m[31mreceived[39m[2m).[22mtoBe[2m([22m[32mexpected[39m[2m) // Object.is equality[22m

Expected: [32m"0.0.2-[7m1[27m"[39m
Received: [31m"0.0.2-[7m0[27m"[39m
at module.exports (evalmachine.<anonymous>:19:26)
at async /sandbox/node_modules/@arcanis/sherlock/lib/executeRepro.js:57:13
at async executeInTempDirectory (/sandbox/node_modules/@arcanis/sherlock/lib/executeRepro.js:18:16)
at async executeRepro (/sandbox/node_modules/@arcanis/sherlock/lib/executeRepro.js:25:12)
at async module.exports../pages/api/sherlock.js.__webpack_exports__.default (/sandbox/.next/server/static/development/pages/api/sherlock.js:140:29)
at async Object.apiResolver (/sandbox/node_modules/next/dist/next-server/server/api-utils.js:46:9)
at async DevServer.handleApiRequest (/sandbox/node_modules/next/dist/next-server/server/next-server.js:449:9)
at async Object.fn (/sandbox/node_modules/next/dist/next-server/server/next-server.js:371:37)
at async Router.execute (/sandbox/node_modules/next/dist/next-server/server/router.js:134:32)
at async DevServer.run (/sandbox/node_modules/next/dist/next-server/server/next-server.js:491:29)
at async DevServer.handleRequest (/sandbox/node_modules/next/dist/next-server/server/next-server.js:144:20)

Workaround

FWIW, deleting stableVersion from package.json before and after bumping the versions does result in the expected behavior.

@AlCalzone correct. You actually only need to remove stableVersion right before you run yarn version <strategy>.

To those coming to this issue looking for a fix, you can make sure this jq script runs before every call to yarn version:

./scripts/remove-stableVersion.sh:

#!/bin/bash

# Remove `stableVersion` before relreasing, as it's buggy.
# https://github.com/yarnpkg/berry/issues/3868
echo "$(jq 'del(.stableVersion)' package.json)" >package.json

package.json:

    "remove-stableVersion": "./scripts/remove-stableVersion.sh",
    "version:prerelease": "yarn run remove-stableVersion && yarn version prerelease",

0xalecks commented 1 year ago

A possibly easier workaround is to just run the version command twice, this seems to work for me. First time it sets it wrong, second time it works. ¯_(ツ)_/¯

DDDDDanica commented 1 year ago

Thanks a lot for the solution @samijaber Another workaround inspired by deleting stableVersion is using following script directly as having permission issues ~

await exec("sed -i '' '/stableVersion/d' package.json");
await exec("sed -i '' '/packageManage/ s/,$//' package.json");

oleksandr-danylchenko commented 7 months ago

A possibly easier workaround is to just run the version command twice, this seems to work for me. First time it sets it wrong, second time it works. ¯(ツ)/¯

Unfortunately, it didn't work for me using Yarn 4.1.1 🤷🏻‍♂️. The version is stuck at the 0.0.2-staging.22

yarnpkg / berry