Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package manager detection #25

Open
arcanis opened this issue Oct 30, 2020 · 4 comments
Open

Package manager detection #25

arcanis opened this issue Oct 30, 2020 · 4 comments

Comments

@arcanis
Copy link
Contributor

arcanis commented Oct 30, 2020

We were discussing with @iansu the case where package managers are detected depending on whether they are or not in the global path (@ljharb mentioned that as well in another thread). Tracking some thoughts:

  • Existing CRA & similar tutorials mention npm, so newcomers might be surprised if it gets installed via Yarn.

  • At the same time, it would be similarly confusing if tools like CRA were to always default to npm, given their current behavior.

  • If we do this Corepack thing, it's at least in part so that all package managers are on the same foot.

  • The problem only affects scaffolders, since existing projects will necessarily already have their install creations.

One potential solution would be to offer a BrowserChoice-like system under the form of a Corepack command (let's say corepack elect for now) that, when called:

  • If the command was never run before, it would print all supported package managers with an interactive interface listing their name and a link towards their respective websites. Upon selecting one of the options, Corepack would save the result inside its data folder, then would print the name of the selected package manager.

  • If the command ran before, it would simply read the data previously stored inside the data folder, and print again without prompting the user.

From the integrator perspective, the way it would work:

  • Instead of checking for Yarn's existence with things like yarn --version, the program would run corepack elect and capture the output. It would then branch depending on the result as before.

  • They could still implement their flags like --use-npm or --use-yarn, so that users can override their choice on a per-command basis.

One nice effect is that this would make it much clearer for the users which package manager they would be using. Right now, it's difficult to know whether Yarn or npm will end up being used unless 1/ you know that CRA has this behavior, and 2/ you remember whether you installed Yarn or not (you may have installed it only for another project a long time ago).

On the minus side it means that tools like CRA would have to add support for this feature, so it would require their input to know how they would feel about this workflow.

@iansu
Copy link

iansu commented Oct 30, 2020

I like this idea in general, both as a user and as a tooling author. cc @nodejs/tooling

The one concern I have from a Create React App perspective is that our whole thing is that we're a zero-config tool. We go out of our way to avoid prompting the user for anything ever.

The biggest reason for this is that a lot of our users are beginners, new to React, new to JavaScript and sometimes even new to programming. Every prompt is an obstacle to the user. If they don't even know what a package manager is or have never heard of npm or yarn or pnpm they might get stuck.

Aside from that, the idea of being able to programatically ask for the user's preferred package manager and use that by default is very appealing.

@arcanis
Copy link
Contributor Author

arcanis commented Nov 23, 2020

I've implemented a first draft in #26

@merceyz
Copy link
Member

merceyz commented Oct 27, 2021

After some back and forth in facebook/create-react-app#11322 create-react-app has been changed to check which package manager invoked it instead of defaulting to Yarn

@nickserv
Copy link

Could we use preferred-pm to set a default when packageManager isn't used, with its result being overridden by an explicit corepack elect? This would make the default logic more consistent with tools like pnpm and Astro, without requiring manual configuration. VSCode also uses which-pm which is a dependency of preferred-pm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants