Closed developer239 closed 5 years ago
There are numerous reasons for this:
Greenkeeper currently has no infrastructure for calling exec()
on an external binary which in turn downloads and potentially executes code from the internet. I hope it is clear that any errors here would be a severe security risk, which we do not take lightheartedly.
Currently Greenkeeper also doesn't keep any project secrets, for npm, or GitHub. This again is a security conscious choice and e.g. supporting an integrated lockfile service that works with private npm packages, would require us to store an npm token. This is again a severe security concern that we don’t wanna do half-heartedly.
Thirdly, everyone’s project is different and usually CI configurations already take all these differences into account. By making lockfile updates external, we take advantage of work already done.
We hope this explains why this is not really a “no brainer”. We take our service and the security of our users and customers very seriously, and as such, we don’t jump into these things without a lot of consideration.
All that said, we’re working on this as we speak, but there’s nothing to announce just yet.
@janl Thanks for the clarification. I didn't realize that there are so many obstacle that you have to overcome.
Thank you for understanding. We’ve just shipped the first iteration of native lockfile support: https://blog.greenkeeper.io/announcing-native-lockfile-support-85381a37a0d0
@janl I mean now it is 1000 % more awesome. :) I have CI and CD set up so now I don't have to keep track of dependencies on my pet open source projects. Thank you.
I was so happy with greenkeeper when it updated
enzyme
andwebpack
for me. Then I found out that lock file is not updated?What is the purpose of this library? Why doesn't greenkeeper update lock file automatically? This should be a no-brainer. 🙂