feat(why): allow specifying a version or range by remypar5 · Pull Request #6992 · yarnpkg/berry

remypar5 · 2025-11-26T15:59:48Z

What's the problem this PR addresses?

Allowing users to specify a version or range for yarn why to find out why a specific version appears in the dependency tree. This is particularly useful if you want to address CVEs.

Closes #6859

How did you fix it?

Check if a version/range is specified and handling it accordingly
For both simple and recursive mode

Checklist

I have read the Contributing Guide.

I have set the packages that need to be released for my changes to be effective.

I will check that all automated PR checks pass before the PR gets reviewed.

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 · 2025-11-27T08:21:41Z

@arcanis are you available to review this? You refactored yarn why some time ago

packages/acceptance-tests/pkg-tests-specs/sources/commands/why.test.ts

packages/plugin-essentials/sources/commands/why.ts

…w-version-range-for-yarn-why

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

packages/plugin-essentials/sources/commands/why.ts

Requested changes have been made

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

packages/acceptance-tests/pkg-tests-specs/sources/commands/why.test.ts

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

clemyan · 2026-02-22T14:32:03Z

Okay, since it is a relatively simple change I went ahead and added the last couple lines of code to push this over the finishing line. The only thing I'm still iffy on is having to make a new set of fixture packages in the tests but cleaning that up can be a separate PR.

remypar5 · 2026-03-03T08:49:16Z

Thank you @clemyan!

When you're ready, please merge it as I'm not allowed to do so

This rerun is to check if the previous failure is because of flakiness Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

… SHA (yarnpkg#7079) When a release partially fails (npm registry issues, network errors, etc.), there's no way to re-run only the publish steps against an already-tagged commit without bumping versions again. ## Changes - **New workflow** `.github/workflows/release-rerun.yml`: `workflow_dispatch` with a required `commit_sha` input that checks out the repo at that SHA and runs `02-release-builds.sh` + `03-release-npm.sh` - **No version bumping**: `01-release-tags.sh` is intentionally absent — this workflow is publish-only - Same environment, permissions (`id-token: write` for provenance), and npm auth setup as the existing release workflows  <details> <summary>Original prompt</summary> ## Summary Add a new manual GitHub Actions workflow that allows triggering the release pipeline at a specific commit SHA without updating package versions. This is useful for re-releasing artifacts that were not properly published the first time around. ## Background The current release workflows are: 1. **`release-branch.yml`** - Releases a new stable version from a specified branch, bumps versions via `01-release-tags.sh`, and publishes 2. **`release-candidate.yml`** - Releases a RC from master, optionally applies new versions via `01-release-tags.sh --prerelease`, and publishes Both workflows always check out a branch (`master` or a specified branch) and optionally run version tagging scripts. There's no way to re-release artifacts from a specific commit when publishing failed partially (e.g., due to network issues, npm registry problems, etc.). ## Requirements Create a new workflow file at `.github/workflows/release-rerun.yml` (or similar name like `republish.yml`) that: 1. **Trigger**: Uses `workflow_dispatch` with a required input for the commit SHA to checkout 2. **Input**: - `commit_sha` (required): The specific commit SHA to checkout and release from 3. **Steps** (follow the pattern from existing release workflows): - Checkout the repository at the specified commit SHA (using `actions/checkout@v4` with `ref: ${{ github.event.inputs.commit_sha }}`) - Fetch all relevant tags (like existing workflows) - Setup Node.js 18.x - Build the CLI binary (same "Build a binary for convenience" step) - **Skip** the "Generate the release commits" step entirely (no version bumping) - Configure npm auth tokens - Run `./scripts/release/02-release-builds.sh` to publish packages - Run `./scripts/release/03-release-npm.sh` to publish the CLI dist package 4. **Permissions**: Include `id-token: write` for provenance statement minting (same as existing workflows) 5. **Environment**: Use the same environment variables as existing workflows: - `node-version: '18.x'` - `NODE_OPTIONS: --max_old_space_size=8192` ## Reference Implementation Use `release-candidate.yml` as the base template but: - Change the input from `apply_versions` to `commit_sha` (required, string type with description like "Commit SHA to release from") - Change the checkout `ref` to use the commit SHA input instead of `master` - Remove the conditional "Generate the release commits" step entirely - Keep the "Upload the releases" step that runs `02-release-builds.sh` and `03-release-npm.sh` ## Workflow Name Use a descriptive name like `'Re-release'` or `'Republish Artifacts'` to make it clear this is for re-running a failed release. The following is the prior conversation context from the user's chat exploration (may be truncated): User: Open a pr on yarnpkg/berry that adds a new manual workflow triggering the release pipeline at a specific commit without updating the package versions. We will use it to re-release artifacts that were not properly published the first time around. Assistant: I'll create a pull request on yarnpkg/berry to add a new manual workflow for triggering the release pipeline at a specific commit without updating package versions. Let me first explore the existing release workflows to understand the current setup. Assistant: Let me look at the existing release workflows to understand the release pipeline structure: Assistant: Now I have a good understanding of the existing release workflows. Let me also check the release scripts to better understand what they do: Assistant: Now I have a good understanding of the existing release workflows. I can see that: 1. `release-candidate.yml` already has an `apply_versions` input that can skip version bumping 2. `release-branch.yml` releases from a specific branch 3. Both workflows use `02-release-builds.sh` and `03-release-npm.sh` to publish artifacts The new workflow should: - Allow specifying a specific commit SHA to checkout - Skip version updates entirely (no `01-release-tags.sh` execution) - Just run the build and publish scripts Let me create the PR: Assistant: I've started a pull request on `yarnpkg/berry` using the Copilot coding agent. The agent will create a new workflow file (likely named `release-rerun.yml` or `republish.yml`) that: 1. **Manually triggered** via `workflow_dispatch` with a required `commit_sha` input 2. **Checks out** the repository at the specified commit SHA 3. **Builds** the CLI binary 4. **Skips version bumping** - no calls to `01-release-tags.sh` 5. **Runs the publish scripts** (`02-release-builds.sh` and `03-release-npm.sh`) to re-release the artifacts This will allow you to re-release packages from any previously-tagged commit when publishing failed partially (e.g., npm registry issues, network problems, etc.). The Copilot coding agent is now working on this task. You can follow the progress in the repository's pull requests - a new PR should appear shortly at [yarnpkg/berry pull requests](https://gith... </details>  *This pull request was created from Copilot chat.* >  --- 📍 Connect Copilot coding agent with [Jira](https://gh.io/cca-jira-docs), [Azure Boards](https://gh.io/cca-azure-boards-docs) or [Linear](https://gh.io/cca-linear-docs) to delegate work to Copilot in one click without leaving your project management tool. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: arcanis <1037931+arcanis@users.noreply.github.com>

Build the CLI without including the git hash for versioning.

This rerun is to check if the previous failure is because of flakiness Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 · 2026-03-25T09:46:09Z

It seems there are multiple issues with the pipeline. They all seem unrelated to changed in the yarn why command. Not sure how to proceed.

@arcanis @clemyan please advise

clemyan · 2026-03-26T14:58:05Z

Yeah Node 25.7 is failing. If the pipelines other than the E2Es and the Node 25 tests are all passing you should be fine

remypar5 · 2026-03-30T09:42:14Z

Yeah Node 25.7 is failing. If the pipelines other than the E2Es and the Node 25 tests are all passing you should be fine

Thank you. If it is good to go, please merge it as I'm not allowed to do so

remypar5 added 3 commits November 26, 2025 16:39

feat(why): allow specifying a version or range

56f6ec7

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

chore: bump versions

7855f00

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

Merge branch 'master' into feat/6859-allow-version-range-for-yarn-why

56fcb00

Merge branch 'master' into feat/6859-allow-version-range-for-yarn-why

aff9cfd

clemyan previously requested changes Dec 11, 2025

View reviewed changes

remypar5 added 5 commits January 6, 2026 11:33

Merge branch 'master' of github.com:yarnpkg/berry into feat/6859-allo…

60e4cb0

…w-version-range-for-yarn-why

test: use targeted dependencies instead of specific

ff997bc

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

refactor: use existing global utility over a local one

a1ae2eb

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

test: add failure for invalid range

6a78d2f

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

refactor: simplify and fail fast

1235171

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 requested a review from clemyan January 6, 2026 15:39

remypar5 added 2 commits January 6, 2026 16:43

chore: remove unused import

9770333

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

chore: retry after flaky test fail

0e4ec7d

clemyan reviewed Jan 19, 2026

View reviewed changes

packages/plugin-essentials/sources/commands/why.ts Outdated Show resolved Hide resolved

chore: remove obsolete code

4298abb

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 requested a review from clemyan February 11, 2026 11:11

clemyan requested changes Feb 14, 2026

View reviewed changes

packages/acceptance-tests/pkg-tests-specs/sources/commands/why.test.ts Outdated Show resolved Hide resolved

test: fix false positive and add new scenario

81c879c

Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 requested a review from clemyan February 19, 2026 13:57

fix: make why fail-fast on non-semver range

0406f58

clemyan previously approved these changes Feb 22, 2026

View reviewed changes

Merge branch 'master' into feat/6859-allow-version-range-for-yarn-why

392fcb6

remypar5 and others added 4 commits March 4, 2026 10:36

chore: re-run pipelines after failing

3831ea5

This rerun is to check if the previous failure is because of flakiness Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

Change default Node.js version to 25.6

929f1dc

Modify build command to exclude git hash

1fc0d2a

Build the CLI without including the git hash for versioning.

remypar5 added 2 commits March 25, 2026 09:10

chore: retry after flaky test fail

14d2850

chore: re-run pipelines after failing

da68f90

This rerun is to check if the previous failure is because of flakiness Signed-off-by: Remy Parzinski <remypar5@users.noreply.github.com>

remypar5 dismissed clemyan’s stale review via da68f90 March 25, 2026 08:10

remypar5 requested a review from arcanis as a code owner March 25, 2026 08:10

Merge branch 'master' into feat/6859-allow-version-range-for-yarn-why

276aea1

Merge branch 'master' into feat/6859-allow-version-range-for-yarn-why

08352b6

clemyan approved these changes Mar 31, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

feat(why): allow specifying a version or range#6992

feat(why): allow specifying a version or range#6992
remypar5 wants to merge 23 commits intoyarnpkg:masterfrom
remypar5:feat/6859-allow-version-range-for-yarn-why

remypar5 commented Nov 26, 2025

Uh oh!

remypar5 commented Nov 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

clemyan commented Feb 22, 2026

Uh oh!

remypar5 commented Mar 3, 2026

Uh oh!

remypar5 commented Mar 25, 2026

Uh oh!

clemyan commented Mar 26, 2026

Uh oh!

remypar5 commented Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

remypar5 commented Nov 26, 2025

What's the problem this PR addresses?

How did you fix it?

Checklist

Uh oh!

remypar5 commented Nov 27, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

clemyan commented Feb 22, 2026

Uh oh!

remypar5 commented Mar 3, 2026

Uh oh!

remypar5 commented Mar 25, 2026

Uh oh!

clemyan commented Mar 26, 2026

Uh oh!

remypar5 commented Mar 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants