[Feature] Support argument prefix on global command name config

[jeiea]

🚀 Feature Request

Support launching React Native debug sessions when the project is executed through a wrapper command (e.g. mise exec).

Reproducible Steps

1. Configure the project to run commands via mise exec.
2. In vscode, press F5 to start a React Native debug session.

Expected Behavior

The application should launch normally via mise and yarn, just as it does when running the same command in a terminal.

Actual Behavior

The debug session fails with the following error in the Debug Console:

An error occurred while launching the application.
'mise exec -- yarn exec -- react-native run-android --no-packager'
An error occurred while executing the command.:
spawn mise exec -- yarn exec -- react-native ENOENT (error code 303)

Root Cause

The React Native VS Code extension appears to treat the entire command string
mise exec -- yarn exec -- react-native ... as a single executable.
As a result, process spawning fails with ENOENT, because only mise is the actual executable and the rest should be treated as arguments.

Proposed Improvement

Allow the debug configuration to specify:

• a command wrapper (e.g. mise exec --)
• or a clear separation between executable and arguments

so that React Native projects using tools like mise, asdf, or other environment managers can be debugged without workarounds.

[EmmaYuan1015]

@jeiea Thanks. This is a valid enhancement request with a real-world use case.
The current behavior is expected, as the extension does not support shell-style parsing and treats the launch command as a single executable.
Supporting wrapper commands would need to be done explicitly and carefully to avoid adding unintended complexity. We’ll keep this issue open for further consideration.

[EmmaYuan1015]

Thank you for the suggestion and for sharing the use case.
We’ll close this for now due to lack of further updates. If there are new findings, concrete proposals, or implementation ideas to share, please let us know and we can reopen and reassess.

[jeiea]

I don't think this is completed. At least close this as not planned.

We’ll close this for now due to lack of further updates. If there are new findings, concrete proposals, or implementation ideas to share, please let us know and we can reopen and reassess.

It’s not entirely clear what kind of new findings, concrete proposals, or implementation ideas you’re expecting here. Are you hoping for the discussion to branch out further and generate ideas?

If this is mainly a matter of priority and not something you intend to work on in the foreseeable future, then closing the issue explicitly as not planned would make sense to me.

Alternatively, if you’re encouraging someone to open a PR, it would be helpful to say so explicitly. In that case, reopening the issue and adding a help wanted label could be a good next step.