# [Bug?]: `yarn version apply --prerelease=<id>` drops the prerelease identifier in 4.18.0

Self-service

• I'd be willing to implement a fix

Describe the bug

Since 4.18.0, yarn version apply --prerelease=<identifier> applies the deferred version bump but silently ignores the prerelease identifier, and no stableVersion is written back to the manifest.

Given a deferred patch release on 1.0.32:

The command exits 0 with no warning, so the failure is invisible in CI. This is a common "back to development" step in release pipelines — after tagging a release, the next dev version is supposed to carry a prerelease suffix. On 4.18.0 the branch is left on a plain release version instead, which then fails downstream checks that assert the working version is a prerelease.

I bisected this to 4.18.0 exactly; 4.17.0 and every earlier 4.x I tested behave as documented. The only version-related change in that release is #7218 ("Version: Reimplement yarn version and yarn version apply"), so I assume the regression was introduced there.

Docs for the flag: https://yarnpkg.com/cli/version/apply

If --prerelease is set, the given prerelease identifier (by default rc.%d) will be used on all new versions and the version definitions will be kept as-is.

To reproduce

Single-package repo, no workspaces, no dependencies.

package.json:

{
  "name": "t",
  "version": "1.0.32-alpha.0",
  "packageManager": "[email protected]"
}

.yarnrc.yml:

nodeLinker: node-modules

Then:

git init -b main && git add -A && git commit -m init

# release bump
yarn version patch                        # -> 1.0.32
git commit -am release

# back to development
yarn version patch --deferred
yarn version apply --prerelease=alpha.0

node -p "require('./package.json').version"

Expected: 1.0.33-alpha.0 Actual (4.18.0): 1.0.33

Swapping packageManager to [email protected] and re-running the exact same steps yields 1.0.33-alpha.0 plus "stableVersion": "1.0.32".

Bisect results, same script, only packageManager changed:

yarn 4.12.0  ->  1.0.33-alpha.0
yarn 4.13.0  ->  1.0.33-alpha.0
yarn 4.14.0  ->  1.0.33-alpha.0
yarn 4.15.0  ->  1.0.33-alpha.0
yarn 4.16.0  ->  1.0.33-alpha.0
yarn 4.17.0  ->  1.0.33-alpha.0
yarn 4.18.0  ->  1.0.33            <-- regression

Environment

System:
    OS: Windows 11 10.0.26200
    CPU: (12) x64 Intel(R) Core(TM) i7-10850H CPU @ 2.70GHz
  Binaries:
    Node: 24.13.0
    Yarn: 4.17.0
    npm: 11.6.2

# Note: envinfo above reports 4.17.0 because the repo has since been pinned back
# to a working version. The reproduction above was run with 4.18.0 resolved via
# corepack from the `packageManager` field.

Additional context

Hit this in a shared GitLab CI release template used across several repos. Every repo on 4.12.0 produces the correct -alpha.0 version; the one repo that had been bumped to 4.18.0 silently produced a plain release version and broke the next pipeline run. Pinning packageManager back to [email protected] resolved it.