greenkeeperio
Pull requests for projects with package-lock.json
Quoting the official documentation:
A dependency updates occurs Greenkeeper will open a branch that bumps that dependency’s version number in your package.json files. Your CI tests will run on that branch, and once they complete, one of three things will happen:
- It’s an in-range update, and your tests pass: Greenkeeper deletes the branch and stays silent, because everything still works!
In-range means: If you specify a range of ^1.0.0, and 1.0.1 is released, that update is in-range. Users of your package would receive this update when they run npm install. Consult npm’s semver calculator to see which updates apply to your specified ranges, per package.
It’s an out-of-range update: Greenkeeper opens a pull request, and your CI runs there. Your users would never encounter this version because it’s out of range, but if the update contains changes you want (security fixes, performance improvements, better compatibility etc.), this pull request is a good basis for work in that regard. Plus, if you trust your tests and they all pass, you could merge the pull request straight away.
While this is a good behavior for projects without package-lock.json files (the users will get the updated version when they run npm install), it won't work for projects with package-lock.json.
In these projects people won't get the updated version until it is updated in the lock file.
And this will happen only if the version update was out of range.
Basically this means that if I'd like my package-lock.json to be up to date, my dependencies should use exact versions (without ~ or ^) so that any update would be out of range, which makes the whole package-lock concept pointless.
I believe the pull requests for the projects with package-lock.json should be created on every version update, while updating only package-lock.json and leaving the package.json as is.
Essentially I suggest to leave the existing behavior with one small change: a pull request with updated package-lock.json will be created on each dependency version update.
First of all great to hear, excellent job! That means I can drop the greenkeeper-lockfile package now.
However the issue with pull requests still stays. Although lock files are supported natively now, the policy of creating pull requests hasn't changed. Which means that all the projects with lock files will be most probably outdated, unless exact dependencies are specified in package.json.
@janl unless I'm missing something.. I think there is a use case that is not currently handled when working with a package-lock.json and npm ci
Greenkeeper will automatically update your package.json and the corresponding lockfile (either package-lock.json or yarn.lock).
Correct me if I am wrong, but Greenkeeper will update package.json and package-lock.json only when an out of range version is published.
So if I have "react": "^16.6.3", in my package.json
and then "16.7.0" is published, so Greenkeeper will pick it up, create a branch with the updated package.json and package-lock.json; at this point 2 things can happen
A. if the build does not pass, Greenkeeper will open a PR asking for my intervention
B. if the build passes and since the new version is in range Greenkeeper will delete the branch and do nothing else.
I have a problem with B.
on my master branch, the CI does not run npm install, it runs npm ci which respect 100% of the package-lock.json (and npm ci does not update it).
What I want from Greenkeeper is the option to tell it to actually merge (yes directly on master) the updated package.json and package-lock.json
Is there something planned to support use cases involving npm ci and automatically commiting in-range update to master?
Thanks!
@meltedspark I have the exact same problem, so for now I have pinned all my deps (no ^ or ~), downside is I have to merge the PR many time per week.
I'd like the options to tell greenkeeper to commit package.json and package-lock.json to master when an in range update is still building fine on my CI
Thanks!
dependabot has this feature... I'd hate to switch to them :( https://dependabot.com/#features
@phil-lgr if you are interested in automatic merging of greenkeeper PRs, be sure to take a look at greenkeeper-keeper, if you haven't already. i'm the maintainer and have found it very valuable for projects where I have the confidence to merge automatically. I'd be interested in feedback if you think it could help you.
Cool I’ll check it out, ideally.. this would be part of greenkeeper itself though
On Wed, Dec 12, 2018 at 4:44 PM Matt Travi <[email protected]mailto:[email protected]> wrote:
@phil-lgrhttps://github.com/phil-lgr if you are interested in automatic merging of greenkeeper PRs, be sure to take a look at greenkeeper-keeperhttps://github.com/greenkeeper-keeper, if you haven't already. i'm the maintainer and have found it very valuable for projects where I have the confidence to merge automatically. I'd be interested in feedback if you think it could help you.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/greenkeeperio/greenkeeper/issues/864#issuecomment-446755611, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AJMrQxP2-5pCl8LkJilosbnHjJMriP1hks5u4Xi6gaJpZM4Vv5_d.
-- Phil Sent from Mobile
ideally.. this would be part of greenkeeper itself though
in a way, i would have liked this early on as well, but i've come around to mostly agree with the greenkeeper team's stance around it. their point is that having all of that power in a single service is putting a lot of trust in a single service.
i feel like an approach with a bot that runs as an account within your org puts a bit more control in your hands and makes being that aggressive to merge more opt-in than just asking to be told about available updates.
i do hope to provide a github app version at some point that could potentially be hosted to save the self hosting setup, but i still would want to support an approach like the current one to support various levels of trust.