fix(deps): update dependency semver to v7.7.1

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
semver	7.7.0 -> 7.7.1

---

Release Notes

npm/node-semver (semver)

v7.7.1

Compare Source

Bug Fixes

• af761c0 #​764 inc: fully capture prerelease identifier (#​764) (@​wraithgar)

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.76%. Comparing base (ebf14c8) to head (dda48f5).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #880   +/-   ##
=======================================
  Coverage   98.76%   98.76%           
=======================================
  Files          21       21           
  Lines        1219     1219           
  Branches      142      142           
=======================================
  Hits         1204     1204           
  Misses         15       15           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rakleed]

@JoshuaKGoldberg is this a bug in Renovate that he indicated the type of commit and PR as a fix instead of chore? He just got into Release notes as Bug Fix because of this: https://github.com/JoshuaKGoldberg/eslint-plugin-package-json/releases/tag/v0.23.1

[michaelfaith]

I think it might just be because semver is a formal dependency of the package rather than a dev dependency? It did the same for #874 and #875, but not #877

[rakleed]

@michaelfaith but in fact, nothing has changed for the eslint-plugin-package-json user, so it’s strange to see the patch update of this dependency in Bug Fixes.

[michaelfaith]

I agree for the most part, for dev tools like this. For some things though dependency changes are meaningful. For instance, when a library bumps a major version of a dependency. Consuming projects might be using that library at the lower version through other packages, which can lead to bundle size bloat, because different bundles will be pulling in different versions of that package. By hiding those changes it can create issues for those consumers.

With that said, that's not really an issue for devtooling usually. So, I can look into adjusting. We recently changed to extend the recommended config from renovate, which includes all the settings they consider best practice.

[JoshuaKGoldberg]

Yeah I think technically this is correct, since semver does get shipped to users & might have changed runtime behavior. But +1 that this is annoying and I wouldn't want a release that only has deps changes.

If Renovate doesn't have a thing for this then we could fall back to changing https://github.com/JoshuaKGoldberg/should-semantic-release. It gates running release-it at the moment.

[michaelfaith]

This is the preset that recommended includes that gives us that functionality. https://docs.renovatebot.com/presets-default/#semanticprefixfixdepschoreothers We could certainly tweak it. The renovate config is extremely flexible, but the more we diverge from recommended, the more of that config we own. So it's a balance. You can see if has a block that maps dependencies to use a fix prefix, chore otherwise.

[michaelfaith]

We would basically just need to add

{
  "matchDepTypes": [
    "dependencies",
  ],
  "semanticCommitType": "chore"
},

to undo that bit of their preset.

[michaelfaith]

Though, even with that, I would probably recommend at least distinguishing major version bumps in the changelog, even if we omitted the others.

[michaelfaith]

That would look something like

[
  {
    "matchDepTypes": [
      "dependencies",
    ],
    "semanticCommitType": "chore"
  },
  {
    "matchDepTypes": [
      "dependencies",
    ],
    "matchUpdateTypes": ["major"],
    "semanticCommitType": "fix"
  },
]

[michaelfaith]

@JoshuaKGoldberg do you have a preference between the above two options? (Marking majors as fix and everthing else chore vs everthing chore)