Ember-try uses `Yarn` in Travis CI Trusty Build

[zhujy8833]

I've experienced the Travis build of my ember-addons throw errors when executing yarn install under ember try:one, the error is because it had troubles to access some of the private npm repos.

Although it is another concern, I was wondering the reason why my Travis build picked Yarn rather than NPM as the package manager. It turns out the condition has been configured as yarn.lock is present and yarn is installed globally since 0.2.12. In my repo I don't have yarn.lock but the fact is I'm using Trusty build of Travis (setting dist: trusty in .travis.yml) and Yarn was preinstalled there.

Is there any option we could set in ember-try to manually configure package managers between Yarn and NPM?

[brlodi]

To add a +1 and some clarification on this, it appears ember-try is opting to use Yarn instead of NPM if it is installed, even when there is no yarn.lock file present in the project (just running it in no-lockfile mode to suppress creating one). I'm curious as to the reasoning behind that, as it is effectively forcing Yarn on projects if the host supports it, considering in many CI environments the global installation of Yarn happens outside the control of the developer.

There are some inconsistencies between how Yarn and NPM work (checking Node engine versions, for instance) that can cause CI tests to fail under one that pass under the other. I'm all for switching to Yarn, but I feel like I should decide when that happens by the presence of a yarn.lock in my project instead of having ember-try decide that's what I should be using.

[snewcomer]

Also curious about this. Have a package-lock.json now in my projects.

[brlodi]

package-lock.json is a new thing in NPM 5.0.0, which has taken a lot of inspiration from Yarn.

[kategengler]

Using yarn is now explicitly chosen via the useYarn: true configuration in config/ember-try.js