Capacitor: Support yarn when installing deps for cap add

[nklayman]

If there is a yarn.lock in the root directory of a capacitor project, running cap add [platform] should install deps with yarn instead of npm. For projects using yarn, adding a platform takes way more time then it should, an a package-lock.json is generated unnecessarily. I could make a PR if requested.

[ptitjes]

I would love that too!

[nklayman]

Created pr #983 for this.

[kxc0re]

wouldn't it be better to just use the default package manager which gets defined in the angular cli ?

or have your own config entry for that matter

[nklayman]

This is better because it works with non-angular projects. The own config entry is more complicated and won't work for the init command.

[nklayman]

What could happen is that the init command detects the yarn.lock, and sets the package manager in the config accordingly.

[mlynch]

Capacitor is a friend to all frameworks, so will make no assumption about which you happen to be using.

One question for this: what if you don't have anything installed yet, thus no yarn lock?

[nklayman]

That is a good point. I can add a command line flag to force yarn or npm usage.

[ptitjes]

@nklayman I think there should be a npmClient configuration, for instance as in lerna config, and also $npm_execpath environment var should be supported (it is set by npm and yarn for sub-processes).

[nklayman]

@ptitjes Are you saying that it should check the $nmp_execpath as well as the config to determine if yarn should be used over npm? What should be the order of priorities then, as there would be 4 ways to check (yarn.lock, $npm_execpath, capacitor.config.json, and --package-manager/--pm)? I think yarn.lock + --package-manager would cover all scenarios without requiring much interaction from the user.

[nklayman]

What about using this for hasYarn?

process.argv.includes('--npm') ? false : process.argv.includes('--yarn') || existsSync(join(process.cwd(), 'yarn.lock'))

That would check for --npm/--yarn and use that, or would use the yarn.lock method.

[ptitjes]

For the configuration, I'd prefer that you use npmClient, which is what other projects, that I know of, use.

Also, it is customary of dev tools in the Node.js world to have command-line flags (in lowerCamelCase) to match configuration flags (in kebab-case). That would give --npm-client <client>.

What should be the order of priorities ?

That's a good question. From the highest to the lowest priority, I would say :

1. check for --npm-client <client> in command line
2. check for npmClient in capacitor.config.json
3. check for $npm_execpath in process.environment
4. check for yarn.lock in project's filesystem root

I think that's a good order, because it goes from the most explicitly specified by the user to least explicitly specified.

[nklayman]

The issue with $npm_execpath is that I often use yarn to run commands in projects using npm, as the run keyword is unnecessary as well as the --. Therefore, I think that $npm_execpath should be ignored. Other than that, I agree with that order. What are your thoughts?

[nklayman]

Latest commit checks capacitor.config.json for npmClient, as well as prompting user during create (only if yarn is installed) and checking for --npm-client (as well as yarn.lock).