chore: update dependency husky to v2.7.0 - autoclosed

[renovate]

This PR contains the following updates:

Package	Type	Update	Change
husky	devDependencies	minor	2.3.0 -> 2.7.0

---

Release Notes

typicode/husky

v2.7.0

Compare Source

Due to issues with Git < 2.13.2, this version is a rollback and is the same as husky v2.4.1. Changes introduced in v2.5.0 and v2.6.0 will be published in v3.0.0.

v2.6.0

Compare Source

• Optional HUSKY_USE_YARN setting to use Yarn to run Husky
• Add more debug information
• Show a warning for Node <= 8.6.0

Deprecated

v2.5.0

Compare Source

• Use more accurate git hooks directory resolution
• Add CWD in debug messages

Deprecated

v2.4.1

Compare Source

• Fix husky crash on install/uninstall with very old Node versions

v2.4.0

Compare Source

• Add HUSKY_SKIP_HOOKS to skip all hooks

---

Renovate configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻️ Rebasing: Whenever PR becomes conflicted, or if you modify the PR title to begin with "rebase!".

🔕 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 has been generated by Renovate Bot. View repository job log here.

[sidharthachatterjee]

@rarkins Any idea why these are getting autoclosed?

[rarkins]

@sidharthachatterjee it's because of this change you made: e7a5214

husky is found in package.json so when you remove package.json from the includePaths then all PRs will be autoclosed, and you also won't get the yarn.lock updates in other PRs anymore either.

[sidharthachatterjee]

@rarkins Oh, got it. Makes sense. I reverted that temporarily so prevent too many merge conflicts (from yarn.lock) for the initial batch!

Will add that back after most of these are in

[rarkins]

You could also add a prConcurrentLimit setting, e.g. only get 2 at a time to reduce the chance of conflicts.

[sidharthachatterjee]

@rarkins I actually want no rate limit at all so I can get them all and batch merge! Haha

Anyway I can fold all these updates into a single PR or PR per package whose package.json is being updated?

[rarkins]

Usually you wouldn't want to group them by package file because then you end up with mismatched/duplicated versions of many dependencies. e.g. you'd update package X inside one packages/* file but be left with the old version of X within all the others (until you merge their PRs).

The one exception might be devDependencies inside the root package.json - you could maybe group all of those together, although then you run the risk that one broken dependency results in the PR tests failing and you can't merge any of them.

[rarkins]

BTW you can group however you want though, including grouping every update together (or all patches, all non-major, etc). It's a tradeoff though because as I mentioned, you increase the chance of one bad update causing the others to be unmergeable.

[sidharthachatterjee]

@rarkins Yeah, that makes sense. I guess it's best to wait and do this incrementally then! Thank you again 💜

[sidharthachatterjee]

@rarkins

BTW you can group however you want though, including grouping every update together (or all patches, all non-major, etc).

How would I group all patches and non major?

One final question: #16840 mentions a rate limit. How do I get rid of it?

And the Closed/Ignored section seems to be listing updates that are merged already?

[rarkins]

How would I group all patches and non major?

By default Renovate doesn't separate patch from minor (i.e. you won't get a separate PR for both patch and minor of the same package), so you probably want to keep that. Then the rule for grouping all non-major is this:

{
  "packageRules": [{
    "updateTypes": ["minor"],
    "groupName": "all non-major"
  }]
}

One final question: #16840 mentions a rate limit. How do I get rid of it?

Add "prHourlyLimit": 0 to your config.

And the Closed/Ignored section seems to be listing updates that are merged already?

This can sometimes happen in large monorepos. If Renovate sees that a particular package has been updated before, it won't raise another PR if the version isn't greater than before. So if you added packages with old versions after the previous PR, you might end up in that situation (they need upgrading, but Renovate thinks it's already upgraded before). In this case tick the checkbox to override.

[sidharthachatterjee]

@rarkins Okay, awesome. I've gone ahead and added a package rule that makes sense. And prHourlyLimit: 0

Will all these get auto closed and a new one opened?

[rarkins]

Any PRs that were raised without yarn.lock updates will be autoclosed or automatically recreated. But you can tick the checkbox for each to have them rebased/recreated. The master issue even lets you do that for all open PRs at once.

[sidharthachatterjee]

@rarkins Yeah, I checked that some time ago on #16840 🙂

Waiting for all of the current ones to get auto closed and for a new one to be opened! 💃

Edit:

But it seems to be opening new ones that don't respect the package rules 🤔 My best guess is these are older requests in the queue perhaps

[rarkins]

It could still be an "old" run waiting to complete. Note: it will reset the master issue back to unchecked again when it's done, so you may need to check again. This is essentially a "race condition" with using Issues for this UI

[sidharthachatterjee]

@rarkins Aha. That makes sense. Let's wait for a while then! Thank you so much once again for all you support 💜 You're incredible!