I'm also not against making an extension for this, but I figured it would be best to propose it internally first for better support with existing features and other extensions.

I am not opposed to an auto option for npm.packageManager.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

@alexr00 I'm willing to work on this one.

Should the development be started only after this issue has moved from Backlog Candidate to the Backlog?

@shivangg thanks for checking, especially since we aren't always consistent about what to do there. If you start working on it I will move it into the current milestone.

More spec-ing details:

I would like npm.packageManager to default to a new auto option, which would select a package manager based on the presence of workspace and lock files using preferred-pm.

Making auto the default sounds good to me.

If a lock file doesn't exist, the user is probably using npm anyway, and we can just default to npm like we already are.

Agree that default should be npm if there is not lock file.

It would also be nice to set up some sort of warning if multiple lock files are found, as most package managers do this to inform users that their package installations can break because of differences in version resolution.

A warning if there are multiple lock files AND auto is set makes sense. There should be no warning if auto is not set. However, it is still possible to simply proceed even if there are multiple lock files. So I would expect the behavior to be continue using one of the package managers and also show a warning notification. I would expect order of priority with multiple lock files to be npm, yarn, then pnpm.

@alexr00 Thanks for the reply. Here's a draft PR.

As preferred-pm exposed an async function to query the preferred package manager, I had to make many of the dependent functions async. Let me know if their if a better/efficient way to prevent this.

@alexr00 I'm not sure of the cleanest way to detect multiple lockfiles. preferred-pm only returns the preferred pm in priority order npm > yarn > pnpm even in case of multiple lockfiles.

Is there a better way to proceed without deduplicating the preferred-pm logic in vs code?

@shivangg, I don't know of a better way.