Make it possible `tns` to use Yarn as the package manager

[dtopuzov]

From @ugultopu on April 24, 2017 17:26

Is it possible to configure Nativescript CLI tool to use Yarn as the package manager?

Copied from original issue: NativeScript/NativeScript#4058

[dtopuzov]

No it is not possible at the moment.

[ishitatsuyuki]

Wait how impossible? This should be a feature request.

[dtopuzov]

Reopen, title update and label question changes with feature.
We will be happy if someone wants to contribute on this feature.

[ibrahimab]

Any word on this? Any milestones so people can help by contributing ?

[rosen-vladimirov]

Hey @ibrahimab ,
Currently we are working on other features and this one is not in our short-term plans. That's why we've added the "help wanted" label. We'll be glad to review PRs adding this functionality.
In order to make it easier for contribution, I would like to share some insides how CLI works and where npm is used. NativeScript CLI uses dependency injection which allows easier bootstrap and testing. More information about this can be found in CLI's submodule.
CLI uses npm for project creation, runtimes installation, plugin manipulation, etc. Basically all npm related operations are in a single file: nodePackageManager.
There are different ways to add support for yarn, but if I have to do it, I would try the following approach:

1. Add a new service for example yarnPackageManager (and register it as $yarn) that implements the same interface as nodePackageManager: INodePackageManager (and maybe rename the interface later).
2. Add a new service that is wrapper for both $npm and $yarn. This service must have a private method that decides if $yarn or $npm will be used. The service must implement the same interface (INodePackageManage). This service can be injected with name $packageManager.
3. Replace all occurrences of $npm with $packageManager.
4. Implement a way for users to switch to yarn. One possible solution is to add a --yarn flag, so in case users want to use yarn, they'll have to pass it. In the private method mentioned in point 2. (inside $packageManager), you can read the value of $options.yarn - if it is true, the user had passed it, so the method will return $yarn. In fact, in code this should look similar to this one (in icenium-cli). The $packageManager will have wrappers for all methods, based on user input it will decide if $npm or $yarn should be called.
   In case we do not want users to pass --yarn on each command, we can add a command that persists the value in the users settings. The new command can be something like tns package manager set yarn or tns package manager set npm. The command will call $userSettingsService.saveSetting("packageManager", "yarn") for example. The $packageManager will be able to read the value and based on it, it will resolve either yarn or npm.

Of course, this is just an idea for implementation and any other suggestions and implementations are welcome.
Hope this information will allow anyone to try implementing this feature.

[ibrahimab]

Hi @rosen-vladimirov thank you for your response. I want to take this up. How would this work? I want to setup milestones, tasks, issues etc. Do I do this on this repository or link to my own fork?
I'm leaning more towards 2 and 3. I want a way that the system detects someone changed to yarn without them changing anything in their package.json. I am also more in favor of setting yarn as the default package manager. Any input on what I just said?