Offer to update `package.json` in addition to the lock file

[Drarig29]

Is there an existing issue for this?

• [X] I have searched the existing issues

Feature description

While it makes sense for most projects to only update the lock file, it's not enough for libraries.

Example:

• My library says in its package.json file that it works with "foo": "^1.0.0"
• A vulnerability is reported for foo and the affected version is 1.0.0
• The dependabot PR changes my library's package-lock.json file to use 1.0.1 instead
• I release a new version of my library
• Consumers upgrade the library in their project
  • Since my library still works with "foo": "^1.0.0", they still have the vulnerable foo@1.0.0 in their project.

Now, if the dependabot PR had changed the package.json file to "foo": "^1.0.1" (in addition to the lock file):

• I release a new version of my library
• Consumers upgrade the library in their project
  • Since my library requires "foo": "^1.0.1", the new foo@1.0.1 is downloaded in their project.

This results in less work for library consumers.

Currently, I can't rely on the automated dependabot PRs because of this, so I always close them and handle the dependency upgrade manually.

So in the end, I mostly use those PRs as a call to action. As a side note, it would be cool for the GitHub & Slack integration to support notifications on security vulnerabilities (https://github.com/integrations/slack/issues/1797).

[Drarig29]

Note that this was mentioned in https://github.com/dependabot/dependabot-core/issues/7639#issuecomment-1680152672:

bump the dependency specification in the package.json to a version range that does not allow any vulnerable version