Refactors the CLI spawn

[arcanis]

What's the problem this PR addresses?

While working on the new website, I find myself in a situation where I need to access Yarn's cli instance (I want to use it to tokenize the examples on the website). This is difficult at the moment, as all parts of the CLI initialization are entangled together.

How did you fix it?

I extracted our initialization steps into separate functions, each called in sequence. The one breaking change I made is that --cwd is now only accepted as very first argument of the command line (this is needed to get rid of the recursive execution which caused various issues) - if it isn't, Yarn will throw an error explaining the problem.

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.

[merceyz]

Note that this breaks create-react-app

Usage Error: The --cwd option is ambiguous when used anywhere else than the very first parameter provided in the command line, before even the command path

$ yarn add [--json] [-F,--fixed] [-E,--exact] [-T,--tilde] [-C,--caret] [-D,--dev] [-P,--peer] [-O,--optional] [--prefer-dev] [-i,--interactive] [--cached] [--mode #0] ...

Aborting installation.
  yarnpkg add --exact react react-dom react-scripts cra-template-typescript --cwd /tmp/tmp.fkuayeuy0I/my-cra-ts has failed.

https://github.com/yarnpkg/berry/actions/runs/5647321283/job/15297186950#step:5:43

Why aren't we letting Clipanion do the CLI argument parsing so that this still works?

[paul-soporan]

Why aren't we letting Clipanion do the CLI argument parsing so that this still works?

We are, but when it detects --cwd it throws (in BaseCommand#validateAndExecute, after clipanion parses it) because that's the most correct thing to do.

Unfortunately, as I described in #5595 (comment), --cwd anywhere other than the first argument is ambiguous, if we want it to actually do the right thing and use the configuration from the target folder.

Imagine yarn foo --cwd=./bar, where ./bar is a separate project that loads a plugin that declares the foo command.

How can we know whether the command is supposed to run the foo script with the --cwd=./bar argument in the current project or whether it's supposed to run the foo command in the ./bar project?

We can't, due to the dynamic nature of the CLI. Because of this, we have 2 options:

• we either only allow --cwd as the first argument which is never ambiguous
• we always treat --cwd as an argument for the CLI even if it's part of a proxy, which is wrong.

Unfortunately we can't just go in ./bar and see whether there's an actual plugin declaring a foo command, as that would lead to different behavior depending on what ./bar contains.

There's also a third option (that I described in that comment):

Technically there's nothing limiting us from still being able to use --cwds that aren't the first argument, but only if they point to a folder that's part of the same project, via detection in validateAndExecute. And it could throw if it points to a different project, telling the user to use it as the first argument. It would still be inconsistent, but any solution we pick is going to be partially inconsistent anyways, so... ¯(ツ)/¯

It might be enough to fix CRA.