Option for ng new to use yarn instead of npm install

[adi]

Is it possible to have a ng new option that replaces the use of npm install with yarn ?

Thank you,
Adrian

[intellix]

Just done a few tests locally with a new angular-cli project and the theory and results are staggering.

yarn: 120s and then 45s after deleting node_modules folder
npm: 155s and always

After an install already to determine there's nothing to do:
yarn: 0.3s
npm: 30s

In my opinion yarn should outright be the default and only way to install, even based on things like lock files by default and deterministic results.

[kylecordes]

I don't have the timings in front of me, but I saw a bigger timing difference than your first pair of numbers above. Of course it varies by hardware etc.

It seems to me that yarn is a very helpful leap forward in the NPM world. Something we have been waiting for for a while, some fundamental improvements (determinism, so important) as well as the practical benefit of being faster. The most pleasing part is that it did not require replacing the repositories or metadata format, this is all benefit obtained by writing different code to run in the client. Of course it's also important to remember that it was just released, and has some ways to go to reach something close to feature parity.

Of relevance to Angular-CLI specifically: CLI pushes NPM quite hard.

• Substantial tree of transitive dependencies
• Heavily used on Windows, where many NPM challenges are exacerbated
• Many people arrive here because they are trying to adopt Angular, and they are grabbing CLI as the very slick tooling to do so, and as a result they are experiencing NPM for the first time, with CLI
• CLI is under ongoing (and extremely helpful) development, so many users uninstall and reinstall regularly

As a result of all these things, yarn is especially big win for CLI, more so than for projects that use fewer dependencies, or changing less often, or are typically used by very experienced NPM users, etc.

[clydin]

For anyone that wants to use yarn right now, no code changes are necessary.
Just use --skip-npm with new/init and then run yarn in the project directory.

[victornoel]

@clydin that's not enough, any of the commands run by ng (such as test or e2e) are run using npm, just do a grep -r npm in angular-cli source code and you will see.
Still, I don't' think it asks for a lot of change to either switch to yarn or have the package manager backend be switchable on demand :)

[clydin]

@victornoel actually it is. NPM is simply being used as a task runner in those cases.

[kylecordes]

I was thinking about how it might be possible for CLI to provide the best experience by default. Whatever experience arrives by default is what most brand-new users will have, and it would be great if those new users could have the yarn experience.

How about this?

• By default, and if it is available, use yarn
• If yarn is not available, by default, use npm install
• If --skip-npm, do nothing; user can then run whichever command they want explicitly afterward

The instructions to get started could then be:

npm i -g yarn
yarn global add angular-cli
ng new blah-blah
...

(Or similar, I typed the above from memory from yesterday and it might not be exactly correct.)

The above idea reflects a philosophy of "likely best results by default, other things optional". An alternative philosophy is "old behavior by default, new behavior optional".

[intellix]

yarn :) sounds good to me to choose it automatically if it exists

[victornoel]

@clydin maybe we are not talking of the same thing :) I realise this issue is about ng new, not ng in general, that's why my comment is not relevant maybe.
Simply, when using other commands than ng new, npm is used, for example when running e2e, link-cli or lint.

[clydin]

Of the commands that use npm, only new, init, and --link-cli use the package management functionality of npm and would therefore interfere with yarn. The e2e and lint commands use npm run which essentially just executes the relevant script. new and init are handled by using --skip-npm. That leaves --link-cli which in general should not be used. It only provides value to someone developing the CLI itself; and in that case it is not really need as it can be done manually afterwards.

This doesn't mean first-class support for yarn wouldn't be useful (at least in the long-term). Especially if yarn doesn't succumb to the package linking bug that renders link-cli practically useless.

[pi0]

Please checkout YarNPM :)

[filipesilva]

There are only two real commands that use npm install, ng new and ng init. On both of them you can opt to forego npm usage by passing in the --skip-npm flag. This means that if you want to use yarn, nothing really stops you now.

I recognize that the speed improvements are dramatic, which is awesome. Install speed is important because no one wants to wait long while starting a new project.

So, hypothetically, Yarn usage would help solve the install problem. Wouldn't address the cause, which is the very large dependency tree, but would help minimize the symptoms.

Now let's talk about the downsides.

It's a new system dependency, of which we only have two at the moment: node4 and npm3. A lot of people don't even realize they need npm3, resulting in a fair number of issues filed. Expecting users to also have yarn is... not really something that's reasonable.

It's another new tech, undoubtedly with its fair share of issues like anything else. This repo already gets a lot of npm issues, not sure I'm looking forward to also have yarn issues being filed against the CLI.

Scope is also something to be considered. Either it's the default and affects the majority of users, or it's a niche optimization. If you're savvy enough to want yarn, you sure are savvy enough to do it manually. To be clear though, no one that's actually participating on this thread is part of the majority. If you've ever looked at the CLI issue tracker, you are not part of the majority.

Lastly there's the issue of configuration. A lot of people have npm configured to their needs. Proxies, private repos, whatever. Stuff that they need on their environment, otherwise they cannot work. I don't think yarn offers parity on that front.

For these reasons I am not a big fan of defaulting to yarn.

Not opposed to having some kind of flag to facilitate yarn usage, but a PR implementing it has to find a way to test it in all CI envs: Linux, OSX and Windows.

[leonletto]

If there comes a point where this is implemented (when?), you can just add an environment variable to select yarn if you want that eg: export ngpm=yarn. Then those who want to use it can easily set that and forget it. The ng-cli developers can then choose the functions which they want to implement yarn support for based on which are consistent.