Update package.json versions from yarn.lock

[simon04]

As a developer, I'd like to see the versions in use from the package.json file. This matches the behaviour when running yarn upgrade-interactive --latest to update versions manually.

Re-configure dependabot's versioning-strategy accordingly, see https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#versioning-strategy.

[gravitystorm]

Hi @simon04 I've looked at this a couple of times in the last few months, but I'm afraid that I don't understand what the point is on making this change, while I see a couple of drawbacks.

If I want to see the specific version that's in use, then that's in yarn.lock. If we need to constrain the version for some reason, e.g. to put a maximum version, then that goes in package.json, and like our Gemfile that's something that's written by hand.

(As an aside, if I could change package.json to generally avoid having any version constraints, like our Gemfile, then I'd be happy with that. But I don't think package.json supports declarations without mentioning any version constraint at all, so we end up with having them. Even for major versions - the chances are reasonably high that if dependency v4 is released, and our test suite passes, then it's fine for us to use it without further scrutiny, and any pessimistic constraint is, well, just being pessimistic. At least for rubygems that is - our javascript is generally less well tested I guess so maybe it's worth being pessimistic there).

So it appears to me that this PR will create lots of noise in the git logs for package.json, which will also make git blame etc much harder to use to e.g. find when a node package was first added. And so updating the minimum version shown in a pessimistic constraint every week or so doesn't really gain us anything useful.

I'm interested in hearing more about your usecase though - or any links you have to explanations as to why package.json should be automatically updated (in addition to yarn.lock). It's not an approach that I've come across before.