Enable users to use yarn for dependency management

[locks]

Rendered: Enable Yarn usage Ember CLI PR: https://github.com/ember-cli/ember-cli/pull/6748

[fivetanley]

I don't really view "continue with npm" as an alternative per se; it seems like an option that should be kept around for a while. yarn isn't at fully compatibility with npm yet (getting close though!), and stuff always gets adopted at a slower rate in enterprise. Careful to be important with messaging here.

[les2]

:+1:

[kategengler]

A downside that I think is worth mentioning: ember-cli often relies on floating dependencies (in each projects package.json) to get bugfixes and new versions out to the community. For example, I could release 0.2.10 of ember-try today and users would use get that new version the next time they npm install, with yarn, that version will be locked until the user explicitly decides to update. How will we get such updates out to users that are using yarn?

Another aspect of the experience to be aware of is upgrades: when upgrading ember-cli with a "^0.2.0" version for a dependency put in package.json by a blueprint the user will get the newest published version that satisfies that semver version statement, with yarn they may get an older version that is already in their lockfile but still satisfies that semver version statement. My concern here is that users will be running more combinations of dependencies that were previously unlikely and possibly untested. This might lead to a new kind of dependency hell unless the user realizes they should look for outdated dependencies. Running yarn upgrade when upgrading ember-cli would probably solve this, but I think it's worth addressing in this RFC as something that needs to be taught.

That said, I'm definitely in favor of having an option for yarn, just adding some considerations.

[buschtoens]

For example, I could release 0.2.10 of ember-try today and users would use get that new version the next time they npm install, with yarn, that version will be locked until the user explicitly decides to update.

I actually prefer the yarn way. At least when working in teams on a single project. With locked versions at least everyone gets the same reproducible bug.

How will we get such updates out to users that are using yarn?

Good question! There are services like Greenkeeper (free for OSS) that automatically notify devs when new versions are released and whether they break builds. This is the ideal solution IMO, but I fear that a majority of teams working on closed source software won't use the paid Greenkeeper service.

Current alternatives for them:

1) Re-build a proprietary self-hosted version of Greenkeeper.

2) Set up a CI job that runs yarn upgrade, diffs the new yarn.lock with the old one and submits a PR, for the latest version in range. It could also run yarn outdated to notify about newly released versions that don't satisfy the range specified in package.json.

3) Do these steps manually or use yarn upgrade-interactive.

A wild idea:

Integrate a mini Greenkeeper into ember-cli (or as an addon) that checks the status every time (maybe at maximum every 30 mins or so) an ember command is run. This mini Greenkeeper could even run in a separate thread / child process, as it has nothing to do with the actual build or stuff ember does.

when upgrading ember-cli with a "^0.2.0" version for a dependency put in package.json by a blueprint the user will get the newest published version that satisfies that semver version statement, with yarn they may get an older version that is already in their lockfile but still satisfies that semver version statement. My concern here is that users will be running more combinations of dependencies that were previously unlikely and possibly untested. This might lead to a new kind of dependency hell unless the user realizes they should look for outdated dependencies.

Addon authors could prevent this by specifying ember-cli as peer dependency. However, quoting from the blog post:

One piece of advice: peer dependency requirements, unlike those for regular dependencies, should be lenient. You should not lock your peer dependencies down to specific patch versions. It would be really annoying if one Chai plugin peer-depended on Chai 1.4.1, while another depended on Chai 1.5.0, simply because the authors were lazy and didn't spend the time figuring out the actual minimum version of Chai they are compatible with.

Teaching addon authors to include ember-cli as a peer dependency could potentially open Pandora's box and introduce real dependency hell.

Running yarn upgrade when upgrading ember-cli would probably solve this, but I think it's worth addressing in this RFC as something that needs to be taught.

Most definitely. A note saying so should be added to the release template "Project Update" section. That note could also recommend running yarn upgrade-interactive instead.

[Turbo87]

@kategengler while I do agree that these are potential issues and need to shift the mindset of JS devs a little bit, I do think that this a general issue with yarn vs. npm, but not directly related to our usage of them in Ember CLI. I think as long as we don't force the user to use yarn we shouldn't have to worry that much about it.

[Turbo87]

Integrate a mini Greenkeeper into ember-cli (or as an addon) that checks the status every time (maybe at maximum every 30 mins or so) an ember command is run. This mini Greenkeeper could even run in a separate thread / child process, as it has nothing to do with the actual build or stuff ember does.

IMHO that is overkill for something like Ember CLI. We shouldn't try to solve every single potential problem in the JS world and instead focus on the really important things

Teaching addon authors to include ember-cli as a peer dependency could potentially open Pandora's box and introduce real dependency hell.

👍

[kategengler]

Yep, I'm just mentioning because I think it's something that will need teaching/clear instructions. I know a lot of developers that will hop on the yarn bandwagon without understanding it or it's implications for workflow.

On Wed, Feb 8, 2017 at 3:16 AM, Tobias Bieniek notifications@github.com wrote:

@kategengler https://github.com/kategengler while I do agree that these are potential issues and need to shift the mindset of JS devs a little bit, I do think that this a general issue with yarn vs. npm, but not directly related to our usage of them in Ember CLI. I think as long as we don't force the user to use yarn we shouldn't have to worry that much about it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ember-cli/rfcs/pull/96#issuecomment-278260650, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbHOitAyosYLcX7sU84AMS9_86Qk6JRks5raXn4gaJpZM4L1ykc .

[kellyselden]

A note on greenkeeper + yarn. I don't think greenkeeper PRs ever touch a yarn.lock file, which make for a less than ideal experience. I'm sure this will be fixed by greenkeeper in the future, if not already in progress.

[rwjblue]

IIRC, it is in the works

[locks]

I know a lot of developers that will hop on the yarn bandwagon without understanding it or it's implications for workflow. — @kategengler

Developers ;P We can add some mitigation strategies to the upgrade instructions we provide in the Guides, what else do you suggest?

[Turbo87]

this RFC was discussed yesterday in the weekly Ember CLI call and it was decided to move this to FCP since we agree with the general direction and the proposed implementation.

[Turbo87]

@locks there is one thing we seem to have forgotten so far: what about the .travis.yml files. I'm assuming when we use ember new --yarn it should generate a .travis.yml file that uses yarn instead of NPM? do we have an idea yet on how those file should look like? for apps we should probably use the lockfile, but do we want to use the lockfile for addons? does it even matter there since ember-try is used?

/cc @kategengler @rwjblue