Skip to content

[Bug?]: YARN_IGNORE_PATH doesn't affect scripts that call yarn #7309

Open

Description

@jfly

Self-service

  • I'd be willing to implement a fix

Describe the bug

If the title isn't clear, see the reproduction below.

To reproduce

package.json:

{
  "name": "yarning",
  "packageManager": "[email protected]",
  "scripts": {
    "hi": "yarn --version"
  }
}

And you need a .yarnrc.yml with a yarnPath pointing to a different version of yarn than the one on your PATH. In the following console session, yarn from my PATH is 4.18.0, but my yarnPath points to 4.18.1.

Note that yarn correctly honors the configured yarnPath, but ignores it if YARN_IGNORE_PATH is set:

$ yarn --version
4.18.1

$ YARN_IGNORE_PATH=true yarn --version
4.18.0

But if we run the script, we see the yarnPath is executed regardless of if YARN_IGNORE_PATH is set:

$ yarn run hi
4.18.1

$ YARN_IGNORE_PATH=true yarn run hi
4.18.1

Environment

System:
    OS: Linux 6.18 cpe:/o:nixos:nixos:26.11 26.11 (Zokor)
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-1260P
  Binaries:
    Node: 24.21.0 - /tmp/xfs-7ca251f4/node
    Yarn: 4.18.1 - /tmp/xfs-7ca251f4/yarn

Additional context

The root cause is that yarn deletes the YARN_IGNORE_PATH environment variable right before invoking the configured yarnPath: https://github.com/yarnpkg/berry/blob/%40yarnpkg/cli/4.18.1/packages/yarnpkg-cli/sources/lib.ts#L158.

This behavior was introduced in #256, and seems to be understood:

One problem is that it causes the settings to never persist - so a user manually adding YARN_IGNORE_PATH in their environment might be confused to see that the local one will still get executed in the nested scripts.

This is one user being confused by this behavior.

It seems to me like the fix is to just undo #256. The PR description has a broken link explaining that we set YARN_IGNORE_PATH somewhere:

and since we set YARN_IGNORE_PATH the nested global instances never reexecute the local ones

I wonder if that behavior still exists and is truly necessary?

Activity

  1. added
    bugSomething isn't working
    on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions