Thanks for the PR! I thought I had replied on #5334 about this, but I can't see anything there now.

If we are to support this, we need to be very explicit with what the expectations of the command output are, and handle all the possible failure cases (non-path output, error codes, failure to spawn the command) well (with tests).

For example:

• in some examples given above, it seems like some of the where calls may output a full path to a binary, and not the path to the SDK folder (as the setting name suggests)
• looking at the asdf code, it seems like asdf where can output strings like "System version is selected".

What's also not clear to me is how big this problem is in practice. We already look in the .dart_tool/package_config.json file to try and locate a Flutter SDK, so as long as you have ever run something like flutter pub get in your project, it seems like we should correctly locate the SDK. Is this not what you're seeing?

@DanTup

in some examples given above, it seems like some of the where calls may output a full path to a binary

Which example would do that? mise in particular outputs the SDK folder. In any case, my vision with this would be a way for a team to configure their project and scripts based on the tools they use. Examples could be added to the docs for well known tools if necessary.

Regarding the package_config.json inference, yes that's currently what we are relying on, but it's only working for Flutter projects. We have several projects in Dart where the version management is really cumbersome, especially when switching branches. The package_config.json unfortunately also requires the user to pub get and reload the vscode window so that the extension works properly.

If you are interested with the idea I'm open to create tests for this, although I would appreciate some guidance on similar tests. I'm not familiar with testing vscode extensions.

Which example would do that?

I'm on Windows so I'm not certain it's a fair comparison, but if I run where.exe flutter I get back:

PS D:\Dev> where.exe flutter
D:\Dev\Google\Flutter\Flutter main\bin\flutter
D:\Dev\Google\Flutter\Flutter main\bin\flutter.bat

Whereas the desired path would be "D:\Dev\Google\Flutter\Flutter main" (although we also tolerate the trailing bin and trim it).

Regarding the package_config.json inference, yes that's currently what we are relying on, but it's only working for Flutter projects. We have several projects in Dart

Ah, that makes more sense, thank you for the extra context :-)

If you are interested with the idea I'm open to create tests for this, although I would appreciate some guidance on similar tests. I'm not familiar with testing vscode extensions.

If we can make the descriptions on the settings more explicit (what the expected output is, what happens if the command fails, error codes, non-path output) I am happy to accept this. I don't know how simple creating the tests will be, but I'd be happy to create at least some basic tests that could be used as a template to add more coverage (for things like errors, or multiple paths in the output like my where.exe example above).

Thanks!

Oh, note that the example is using mise in the executable json field. where is an argument here. It works different than native which (Unix) and where (Windows).

Great! In that case I'll write more in the description of the command.

A few questions on decisions I took with the implementation:

• Failed command:
  Non zero exit code is considered an error, but it's only logged, the user cannot tell what happened. Maybe there is a better way to handle this situation with a vscode notification.

• Working directory on the command:
  Because the SDK is obtained in global context of the extension, we need to infer where we want to run the command. I created a separate function that sets a different work dir based on the vscode workspace config (single/multi root). Are you ok with the current implementation?

Failed command:
Non zero exit code is considered an error, but it's only logged, the user cannot tell what happened. Maybe there is a better way to handle this situation with a vscode notification.

Yep, I think if the command fails to produce a single path in any case, we should log this as a warning (there's an existing logger that should be accessible) and also show a warning toast (see warnIfBadConfigSdk for some existing code that shows a warning) to inform the user the command failed and will be ignored.

Adding some tests in #5395, will merge if/when they're all green.

Great, thank you!

@davidmartos96 I published a pre-release extension that included this change if you'd like to try it out before it ships in a stable release (despite the name, the pre-release versions of the extension should be pretty stable - I just push them a little in advance of stable releases to get some additional coverage before everyone gets them):

The version number that contains this change is 3.103.20250121.

Thank you, we will try it out with our projects