[Snyk] Upgrade husky from 6.0.0 to 7.0.4

[snyk-bot]

Snyk has created this PR to upgrade husky from 6.0.0 to 7.0.4.

ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

---

Warning: This is a major version upgrade, and may be a breaking change.

• The recommended version is 5 versions ahead of your current version.
• The recommended version was released 3 months ago, on 2021-10-21.

The recommended version fixes:

Severity	Issue	PriorityScore (*)	Exploit Maturity
	Regular Expression Denial of Service (ReDoS) SNYK-JS-ANSIREGEX-1583908	482/1000 Why? Proof of Concept exploit, CVSS 7.5	Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Release notes

Package name: husky

• 7.0.4 - 2021-10-21
  

  No changes. Husky v7.0.3 was reverted, this version is the same as v7.0.2.

• 7.0.3 - 2021-10-21
  

  7.0.3

• 7.0.2 - 2021-08-25
  

  Fix pre-commit hook in WebStorm (#1023)

• 7.0.1 - 2021-07-06
  
  • Fix gracefully fail if Git command is not found #1003 (same as in v6)
• 7.0.0 - 2021-07-01
  
  • Improve .husky/ directory structure. .husky/.gitignore is now unnecessary and can be removed.
  • Improve error output (shorter)
  • Update husky-init CLI
  • Update husky-4-to-7 CLI
  • Drop Node 10 support

  Please help me develop and release OSS projects ❤️ on GitHub Sponsors or Open Collective. Thank you for your support!

• 6.0.0 - 2021-03-29
  

  After being in early access for Open Source projects and Sponsors for a limited time, I'm happy to announce that husky 6 is MIT again and can be freely used in commercial projects! 🎉

  Many thanks to the Open Source projects and Companies which have switched to/sponsored the new husky during this period!

  OSS is my full-time job, please consider sponsoring the development of husky on GitHub sponsors or Open Collective. Thank you!

  Breaking change

  • husky init has been moved to its own package (npx husky-init)

  Added

  • Programmatically use husky: require('husky')
  • TypeScript definitions

  Migrating from husky 4

  Husky 6 contains breaking changes. If you're coming from v4, npm install husky@6 won't be enough.

  Recommended: see husky-4-to-6 CLI to automatically migrate your config. There's also a dedicated section in the docs.

  If you're curious why config has changed, you may be interested in reading:
  https://blog.typicode.com/husky-git-hooks-javascript-config/

  Also Husky 6 follows official npm and Yarn best practices regarding autoinstall. It's recommended to use prepare script instead (see usage in docs).

from husky GitHub release notes

Commit messages

Package name: husky

• 38083d3 7.0.4
• a0e9cd4 revert: unsupported preuninstall
• 5856b5f 7.0.3
• fa4feb8 fix: on uninstall unset git core.hooksPath
• 29fea56 fix(actions): fix action name display (#1059)
• 9c4cad5 docs: update "hooks not running" section
• c86dde9 fix: update npm parameters on `docs/README.md` (#1037)
• 3f19f5b docs: add `npx husky add` workaround on Windows
• e134db1 fix: docs link
• 74ce9c5 7.0.2
• 6b82f37 Fix pre-commit hook in WebStorm (#1023)
• 70d6c71 docs: update
• f757b13 docs: update README.md
• 36c52b9 ci: update actions/setup-node to v2, enable cache (#1008)
• 24c6588 fix: readme confusin condition to disable install in CI (#1005)
• a80ead5 test: add test
• f248876 7.0.1
• cf2e50c style: comment
• 56b9306 fix: cover case where git rev-parse returns null (#1001)
• 50ea409 docs: update Docker section
• 8c7d015 Create stale.yml
• 2917a94 docs: update Docker section
• 1c46e27 docs: update
• 9cdda8e docs: typo

Compare

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.

For more information:

🧐 View latest project report

🛠 Adjust upgrade PR settings

🔕 Ignore this dependency or unsubscribe from future upgrade PRs

[pull-request-quantifier-deprecated]

This PR has 2 quantified lines of changes. In general, a change size of upto 200 lines is ideal for the best PR experience!

---

Quantification details

Label      : Extra Small
Size       : +1 -1
Percentile : 0.8%

Total files changed: 1

Change summary by file extension:
.json : +1 -1

Change counts above are quantified counts, based on the PullRequestQuantifier customizations.

Why proper sizing of changes matters

Optimal pull request sizes drive a better predictable PR flow as they strike a
balance between between PR complexity and PR review overhead. PRs within the
optimal size (typical small, or medium sized PRs) mean:

• Fast and predictable releases to production:
  • Optimal size changes are more likely to be reviewed faster with fewer
    iterations.
  • Similarity in low PR complexity drives similar review times.
• Review quality is likely higher as complexity is lower:
  • Bugs are more likely to be detected.
  • Code inconsistencies are more likely to be detetcted.
• Knowledge sharing is improved within the participants:
  • Small portions can be assimilated better.
• Better engineering practices are exercised:
  • Solving big problems by dividing them in well contained, smaller problems.
  • Exercising separation of concerns within the code changes.

What can I do to optimize my changes

• Use the PullRequestQuantifier to quantify your PR accurately
  • Create a context profile for your repo using the context generator
  • Exclude files that are not necessary to be reviewed or do not increase the review complexity. Example: Autogenerated code, docs, project IDE setting files, binaries, etc. Check out the Excluded section from your prquantifier.yaml context profile.
  • Understand your typical change complexity, drive towards the desired complexity by adjusting the label mapping in your prquantifier.yaml context profile.
  • Only use the labels that matter to you, see context specification to customize your prquantifier.yaml context profile.
• Change your engineering behaviors
  • For PRs that fall outside of the desired spectrum, review the details and check if:
    • Your PR could be split in smaller, self-contained PRs instead
    • Your PR only solves one particular issue. (For example, don't refactor and code new features in the same PR).

How to interpret the change counts in git diff output

• One line was added: +1 -0
• One line was deleted: +0 -1
• One line was modified: +1 -1 (git diff doesn't know about modified, it will
  interpret that line like one addition plus one deletion)
• Change percentiles: Change characteristics (addition, deletion, modification)
  of this PR in relation to all other PRs within the repository.

---

Was this comment helpful? 👍  :ok_hand:  :thumbsdown: (Email)
Customize PullRequestQuantifier for this repository.