Support yarn?

[kentcdodds]

This was just a thought that came to my head. But would ya'll consider supporting yarn? Seems like it'd be really useful here because the yarn.lock locks down the package versions and maintainers would probably like to keep that up to date. I envision seeing pull requests that update the yarn.lock and potentially the package.json if the version range is out of date.

[rkuykendall]

As far as I can tell, the package.json is exactly the same in yarn as it is in NPM, so greenkeeper as it is would work just fine with yarn. However, there is a proposed feature update npm-shrinkwrap.json if exists, which would present a feature difference in NPM vs Yarn. You may want to leave a comment there, since this seems more like a variant on that feature than a change to anything existing.

[kentcdodds]

Yeah, maybe these could be merged, but I was thinking more specifically:

I envision seeing pull requests that update the yarn.lock and potentially the package.json if the version range is out of date.

Greenkeeper doesn't support this yet, and that's why I filed this issue. Happy to merge them though. But I think the work required will be pretty different.

[boennemann]

We would love to send updates to the yarn.lock file along with our pull requests. Especially because that would be a deterministic operation, that doesn't require a file system, like shrinkwrap does.

We are operating Greenkeeper without any outside investment into the company. We want to build a business that must only serve the community we are building this for, which of course includes ourselves, but not any investors.

With the very limited resources we're having because of this, we decided to focus our engineering efforts on migrating Greenkeeper over to GitHub integrations as fast as possible. It doesn't sound like that big of a change, but it's changing a lot behind the curtains.

I think that Yarn and Greenkeeper could be an excellent match, but unfortunately they did not reach out to us prior to their public launch.

They pride themselves as an open community project, and that their ideas were discussed and validated by a lot of people. I'm sad to see that we weren't part of that group.

All I'm left with now is the very sad task to tell you that this isn't going to land anytime soon. It could have been different a few weeks ago when we set our current roadmap.

We're trying our very best to get this to you as soon as possible, and hope you understand our current priorities.

Thank you,
Stephan

[kentcdodds]

Thanks for the explanation @boennemann! Best of luck on your endeavors! I appreciate all that you do for the community. Looking forward to when you can get around to this!

[jasonLaster]

@boennemann I completely see where you're coming from.

I'd be happy to help implement this feature as it could be a really nice win for yarn projects. Do you think you could provide some tips on how to do this? I understand if it is out of scope and that's fine too.

Also as a sidenote I took a quick glance through the code and found evilhackerdude and some other random files. :P what's the story there?

[danielkcz]

I am actually wondering if this could be solved on the CI side, eg. Travis. When greenkeeper makes a pull request, Travis could spot a difference in package.json, run yarn and commit updated yarn.lock to the PR. It might be a long shot and I don't have that much experience with Travis customization just yet. Opinions?

[kentcdodds]

Thanks for the idea, but the PR should update the lock file too

[kentcdodds]

Oh, misunderstood your comment. Yes, this would still require work on greenkeepers part

[danielkcz]

Really? How so? Once there is a PR, the greenkeeper doesn't care about it anymore, right? So if Travis can just commit to that PR with updated yarn.lock, everything should be just fine.

Thinking about it, there actually no need to check on change in package.json, because yarn takes care of it. After successful build, the Travis would just need to commit yarn.lock if it has changed during run.

[danielkcz]

There is a slight issue when build is actually executed for a multiple environments (node versions). It would be necessary to specify which version is used for this update I guess.

[danielkcz]

I guess this is no longer that hot idea after recent discoveries: https://medium.com/@boennemann/avoid-yarn-for-packages-and-fully-enjoy-its-benefits-for-application-development-8bdd4deb33cf#.vnapi4xvi

For open source apps it can still find it's use, but there is a probably much lower number than modules.

[steebchen]

It would be cool to know whether this will be implemented in Greenkeeper since that would be one of a few reasons to switch from private Bitbucket to private Github.