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

Determine automatically the package manager #918

Closed
kcampion opened this issue Apr 17, 2018 · 7 comments
Closed

Determine automatically the package manager #918

kcampion opened this issue Apr 17, 2018 · 7 comments

Comments

@kcampion
Copy link

Expected Behavior

When we use $ bit init, it should be great if "bit" detects the package manager automatically and sets the good value for packageManager into bit.json.

It's easy to determine the default package manager used into a project:

  • package-lock.json for NPM
  • yarn.lock for Yarn.

Actual Behavior

When we do a $ bit init, packageManager is configured with "npm" by default.

@GiladShoham
Copy link
Member

Great suggestion @kcampion .
We will add it to our backlog.
Thanks.

@GiladShoham
Copy link
Member

Update: I've started to work on this feature (along with some other cool features for bit init) in this branch: https://github.com/teambit/bit/tree/feature/interactive-init

@itaymendel
Copy link
Contributor

I'm not sure that Bit should decide on the package manager automatically. I'm seeing a lot of projects that switch between these tools every other day... As each has its own faults.
The fact that there's a yarn.lock in a project does not mean that this is the preferred method.

While this should be solved by a better experience for bit init (for example using params or even an interactive init process), I don't think that an automated process is a correct approach.
I'm leaving this issue open for now to see if there are any feedbacks.

@davidfirst
Copy link
Member

As additional feedback, the following issue: #1578 wouldn't happen if Bit was automatically recognized Yarn as the package manager.

@orinokai
Copy link

An interactive init process probably makes the most sense, but a yarn.lock in the repo is a pretty good indicator IMO, so the init process could suggest Yarn based on this

@GiladShoham
Copy link
Member

@orinokai There is a lot of cases when you have both yarn.lock and pacakge-lock.json.
I might change the interactive init in a way that if I see yarn.lock file, the default value for the interactive will be yarn, otherwise it will be npm.

@itaymendel
Copy link
Contributor

Resolved using the interactive flow of bit init.

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

No branches or pull requests

5 participants