yarn detection isn't complete

[kellyselden]

On new Travis trusty builds, they include yarn v0.17.8 by default. This breaks here
https://travis-ci.org/ember-vr/ember-aframe-camera-extras/jobs/251025550#L2614-L2629

We should check for a yarn.lock file as well, so we aren't accidentally running yarn.

[kategengler]

Re: Checking for a yarn.lock

We had intentionally decided not to check for a yarn.lock and to use yarn if it was installed, just for the speedup. Since this seems to have caused problems we should re-eval. #125 is related.

Adding --ignore-engines seems good.

[kellyselden]

Probably an ignorant question: If the app has already been npm installed (no yarn.lock), and ember-try uses a yarn install to do the swapping of libs, it has to do yarn's complete indexing (assumption based on no yarn.lock file). Would npm be faster in this case?

[kategengler]

No idea, @rwjblue?

[rwjblue]

For NPM <= 4 Yarn was still faster (by a fairly large margin) even when used without an existing lock file. I haven't tested with npm@5.

[backspace]

Is there an elegant way around this? ember-pouch builds have been failing on Travis’s Trusty images because of it; it doesn’t use Yarn but that didn’t matter until it came preinstalled on Trusty. I experimented in this PR with a hideous workaround involving overriding $PATH to prioritise a fake yarn as well as with overriding Ember CLI’s built-in ember-try with 0.2.11, which predates Yarn support.

The older version override has worked to get the jobs passing on Trusty.

I could try a PR for skipping yarn unless a lockfile is present, maybe it’s as simple as changing _runYarnCheck() to run yarn why or some other command that fails when there’s no lockfile?

yarn why v0.23.2
error No lockfile in this directory. Run `yarn install` to generate one.
➜ echo $?
1

[kategengler]

I think with the problems that have cropped up and with npm@5 more directly competing with yarn, making ember-try only use yarn when a yarn.lock is in the project makes sense. @backspace your PR would be most welcome, but I think looking for the yarn.lock file directly would be preferable because yarn why might not always behave that way.

[kellyselden]

All issues are now solved since #138