45 ms·

That would be nice. It could even run on top of the GH Actions infrastructure now. Reading between the lines from comments in that thread, it seems like part o

That would be nice. It could even run on top of the GH Actions infrastructure now. Reading between the lines from comments in that thread, it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic to do in-place lockfile updates behind the scenes. I'm sure it is nice to avoid checking out the whole repo, but it would also multiply the maintenance workload exponentially.

asciimike 4y ago
> That would be nice. It could even run on top of the GH Actions infrastructure now. https://github.com/thepwagner/action-update https://github.com/thepwagner/action-update being an example of this (and showing go, docker) > it seems like part of the overhead in maintaining dependabot is that there is ruby code reimplementing yarn logic The entire maintenance burden of dependabot is "reimplement logic that package managers already do to determine the update strategy." Using package managers functionality for this would indeed make this a lot easier, though even then package manager support for specific things might not be universal. That said, it's possibly easier to go to the package manager and say "we'd like to implement/for you to implement feature X that will enable Dependabot as well as the underlying functionality Dependabot was missing, that your users probably already want" than the opposite problem of people asking Dependabot to write a bunch of ruby to re-implement something that already exists.