Knip doesn't parse arguments of yarn run --top-level correctly

[Jym77]

Reproduction url

Sandbox

Description of the issue

In a monorepo setting, a workspace script invoking a top-level script which takes positional parameters gets these parameters incorrectly interpreted as scripts (and reported) by knip

---

Top-level package.json:

"scripts": {
    "echo": "echo"
  },

Here, the echo script just calls the echo shell command, which takes extra parameters on the command line.

Workspace (packages/shared) package.json:

"scripts": {
    "foo": "yarn run --top-level echo hello"
  }

This uses the --top-level flag which seems to not exist in yarn 1. It simply calls the top-level script, providing a parameter to it.

When running (from the toplevel) yarn workspace @monorepo/shared run foo, or (from the workspace directory) yarn foo, I get the correct behaviour (display hello in the terminal).

When running yarn knip, I get:

Unlisted binaries (2)
...
hello  packages/shared/package.json

So, it seems that knip is interpreting the command as running echo and hello scripts.
Adding a hello script inside the package does remove the reporting. Adding one at toplevel doesn't.

This may be related to #735 but I believe it is different.

---

I was not able to reproduce this in a basic (single workspace) setting; Without the --top-level option (and using an echo script in the workspace), hello is not reported, so the option may have something to do with it.

Somehow, removing the echo script from the top-level is not reported. Maybe knip interpretes yarn run --top-level echo hello as being an option --top-level echo and calling script hello (instead of option --top-level and calling script echo with parameter hello).

[webpro]

Knip does not understand the --top-level argument. Unknown arguments are treated as string arguments, so e.g. --top-level echo is basically ignored. Knip does not actually use Yarn for argument interpretation. So indeed your thinking seems correct to me.

This may be related to #735 but I believe it is different.

Why do you think it's different?

[Jym77]

This may be related to #735 but I believe it is different.

Why do you think it's different?

#735 (and the linked #433) seemed related to Github action on first read.
Looking more, #735 may have something to do with parsing CLI arguments, but there knip correctly detects the script name, and incorrectly doesn't find it (as it looks in the wrong directory). Here, knip incorrectly detects the script name, and ("correctly") reports it as missing (that script indeed does not exist).

But indeed, they may both boil down to the fact that --foo bar is effectively discarded while in both cases (--cwd, --top-level) it actually has a meaning that should impact knip behaviour.