Open kevindice opened 7 months ago
I like the idea, but my concern is that we need to audit every single bump to dependencies to see if any of our native code has changed and, if so, we are then required to push a new binary build to the store which might take folks two weeks to pick up. We appreciate being able to OTA on a dime. Being able to use this as a point-in-time tool instead so the branch is OTA-able at any point would be nice. I guess we can also just keep the PRs open until we're ready to do a new build? WDYT?
I like the idea, but my concern is that we need to audit every single bump to dependencies to see if any of our native code has changed and, if so, we are then required to push a new binary build to the store which might take folks two weeks to pick up. We appreciate being able to OTA on a dime. Being able to use this as a point-in-time tool instead so the branch is OTA-able at any point would be nice. I guess we can also just keep the PRs open until we're ready to do a new build? WDYT?
I echo this -- I also like this but since we dont have someone who is actively going to resolve and push there updates, I worry this helpful tool can become more of chore when we do get around to bumping stuff (i.e. to have lots of prs to close/review vs doing it in one swoop) is there a magical software (or setting) where you can tell it to bump all dependencies that have changed like once a month or every few months in a single PR or something like that? That would most certainly work better for our special case.
It supports scheduling - https://docs.renovatebot.com/getting-started/use-cases/#scheduled-updates Can do once a month, bi-weekly, etc. It even supports crontab format.
my concern is that we need to audit every single bump to dependencies to see if any of our native code has changed
Yes, but this also the case if we continued managing dependencies w/o this tool. Being able to OTA update is a nice to have, and we can ensure we have that ability most of the time by:
Re: the awareness piece - The Renovate PRs all come with a changelog in the PR description that highlights the changes from <previous version>
-> <current version>
. So it's convenient in that you don't have to chase down the source repo and dig through it. It's all linked there in the PR.
My gut feeling would be that monthly or bi-monthly makes sense. (thoughts?) With an overhead item like dependency management, there is often indefinite ownership like you mention. The value in automating here is that dependency updating is still nudged along at an institutional level even if no one person is consistently championing it.
Just added some scheduling examples here. Also moved some dev-only dependencies to the devDependenceis
section in package.json
@kevindice looks good! One last question - is there any way to reconcile this tool with the output of the Expo dependency linter? For the subset of packages that Expo has a really strong opinion over I think we'd always want to pin to whatever versions they have validated.
Pending discussion and a repo/org admin to enable a Renovate integration. Renovate is an automated dependency updating tool, much like Dependabot, which has more configuration options for things like rate limiting and having a bit of a delay in the name of stability (to back off of bleeding edge releases). Goal is to get us a nice balance between staying up to date on deps and not having dep management be too noisy.