[Bug] `--cwd` gets ignored when specified inside package.json script

[Knagis]

• I'd be willing to implement a fix

Describe the bug

{
  "scripts": {
    "foo": "yarn --cwd .yarn exec cd"
  }
}

Running yarn foo prints out the current path, not .yarn as specified in --cwd.

Running yarn --cwd .yarn exec cd directly in the shell produces the correct output.

To Reproduce

Use the following package.json

{
  "name": "foo",
  "version": "1.0.0",
  "license": "MIT",
  "scripts": {
    "foo": "yarn --cwd .yarn exec cd"
  }
}

Run yarn foo from the package directorty.

Environment if relevant

• OS: Windows 10 v2004
• Node version: 12.13.1
• Yarn version: 2.4.0

[arcanis]

That's expected, exec runs from the closest package, ie the root. No idea why you'd want to --cwd .yarn 🤔

[Knagis]

--cwd .yarn was just an example.

The actual usecase in our repo (being migrated from yarn 1) is

"install-related": "yarn --cwd ../another-package install"

we use this because when one package depends on another in a monorepo to install those related dependencies.

Another example:

"test": "jest && yarn --cwd packages/foo test"

[Knagis]

@arcanis - though if you say it is expected - why is there a difference in behavior when the command is launched directly from the shell and when it is specified in scripts?

[arcanis]

I'm confused why you'd do that - aren't you basically reimplementing workspaces?

That aside, I was wrong in my previous message (exec doesn't actually crawl up the fs hierarchy), but there is still no problem I can see:

$ ❯ yarn --cwd .yarn exec pwd

/tmp/app/.yarn

[Knagis]

We are reimplementing them (kind of), since we have used yarn1 for a long time. In migration to yarn2 the first step is to make it work as is and only then work on enabling workspaces (and pnp hopefully afterwards).

as for the example: yes, running the command from shell produces the correct output. However, if the exact same command is specified in package.json script, the --cwd arg there no longer has any effect.

[merceyz]

You can replicate that setup if you set the workspaces field in the root and set nmHoistingLimits: workspaces in .yarnrc.yml, except for the yarn.lock moving to the root it will behave the same

[Knagis]

That would only solve install, not running other tasks though.

[merceyz]

This is a valid issue, you're running into #1812 (comment), as a workaround you can specify the path as the first argument

yarn ../another/package exec pwd

[Knagis]

Thank you! That workaround seems to be working.