Parsing of current project fails when using workspace plugins

[mattlewis92]

Current Behavior

Passing a project name to the last arg of an nx command fails when the executor is a workspace nx plugin e.g. nx target-name --foo=bar project-name errors out with Both project and target have to be specified

Expected Behavior

Project name is detected correctly. This works as expected when using regular targets and only fails when the target is a workspace nx plugin. This used to work until 17.3.2 and I believe was broken by #19858

GitHub Repo

https://github.com/mattlewis92/nx-plugin-cli-bug

Steps to Reproduce

1. git clone https://github.com/mattlewis92/nx-plugin-cli-bug.git
2. cd nx-plugin-cli-bug
3. npm i
4. npm run repro nx-plugin-cli-bug and observe that Both project and target have to be specified is logged

Nx Report

Node   : 20.10.0
OS     : darwin-arm64
npm    : 10.2.3

nx (global)        : 16.10.0
nx                 : 18.3.0
@nx/js             : 18.3.0
@nx/jest           : 18.3.0
@nx/linter         : 18.3.0
@nx/eslint         : 18.3.0
@nx/workspace      : 18.3.0
@nx/angular        : 18.3.0
@nx/devkit         : 18.3.0
@nx/eslint-plugin  : 18.3.0
@nx/plugin         : 18.3.0
@nrwl/tao          : 18.3.0
@nx/web            : 18.3.0
@nx/webpack        : 18.3.0
typescript         : 5.4.5
---------------------------------------
Local workspace plugins:
         @myorg/my-plugin

Failure Logs

Both project and target have to be specified

Package Manager Version

10.2.3

Operating System

• macOS
• Linux
• Windows
• Other (Please specify)

Additional Information

Our use case is that we have a bunch of npm scripts for various environments / setups with different cli args, that we allow engineers to pass in the app name to the script for convenience e.g. things like npm start <app-name>

[AgentEnder]

Supplying project​ as a positional at the end like that wasn't meant to be a supported form of the command. There are a few things you could try to keep the same ergonomics... 

Assuming your current script looks something like this:

• "start": "nx serve --someArg value"​

The following command may suit your use case:

• "start":  "nx run-many -t serve --someArg value --projects"​

Alternatively, you could potentially remove many of the flags that are being passed by either moving them into the project configuration or nx.json depending on which flags are being passed. If this is the case, and you were to eliminate someArg​ from being needed, the script could be simplified to "start": "nx serve"​, or developers could simply start using nx serve​ directly.

The only 3 intended ways to run a single Nx target are:

• nx run-many -t [target] -p [project]​ 
  • This one works for the above workaround where we want to pass some flags inside the script definition.
  • Typically would only be used for multiple projects at a time, but can work for single.
• nx run [project][:target][:configuration] [...args]​
  • Args only at end, but target declaration is super explicit. 
• nx [target] [project] [...args]​
  • "infix" notation
  • Sometimes no project​, e.g. if cwd is inside a projects root

It is very true that the positional at the end did work in the past, but I don't think this is something that we're likely to support in the future.

The recommendation from our side would be to migrate away from having to pass flags directly on the CLI level, and get your npm script down to just nx serve.