[Snyk] Upgrade jsdoc from 3.4.3 to 3.6.7

[snyk-bot]

Snyk has created this PR to upgrade jsdoc from 3.4.3 to 3.6.7.

ℹ️ 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.

---

• The recommended version is 14 versions ahead of your current version.
• The recommended version was released 2 months ago, on 2021-05-15.

The recommended version fixes:

Severity	Issue	PriorityScore (*)	Exploit Maturity
	Arbitrary Code Injection SNYK-JS-UNDERSCORE-1080984	596/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 5.5	Proof of Concept
	Regular Expression Denial of Service (ReDoS) SNYK-JS-MARKED-451540	596/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 5.5	No Known Exploit
	Regular Expression Denial of Service (ReDoS) SNYK-JS-MARKED-174116	596/1000 Why? Proof of Concept exploit, Has a fix available, CVSS 5.5	No Known Exploit

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

Release notes

Package name: jsdoc

• 3.6.7 - 2021-05-15
  

  3.6.7

• 3.6.6 - 2020-09-20
• 3.6.5 - 2020-07-22
• 3.6.4 - 2020-04-06
• 3.6.3 - 2019-07-14
• 3.6.2 - 2019-05-12
• 3.6.1 - 2019-05-05
• 3.6.0 - 2019-05-04
• 3.5.5 - 2017-09-14
• 3.5.4 - 2017-08-04
• 3.5.3 - 2017-07-14
• 3.5.2 - 2017-07-12
• 3.5.1 - 2017-07-10
• 3.5.0 - 2017-07-10
• 3.4.3 - 2016-11-10

from jsdoc GitHub release notes

Commit messages

Package name: jsdoc

• e1f1919 3.6.7
• f7a64bd chore(deps): update selected dependencies
• 3f5c462 3.6.6
• 95e3192 fix: correctly track interface members
• ef05a69 3.6.5
• a59b5cd fix: prevent circular refs when params have the same type expression
• 8d0fce6 chore: bump version; update release notes
• 91c9aa7 chore(deps): update dependencies
• ef33f07 3.6.3
• 0e468af 3.6.2
• d5e0eb0 Add 3.6.2 changelog.
• 61ae11c Ensure that ES 2015 classes appear in the generated docs when they're supposed to. (#1644)
• 03b8abd Add 3.6.1 changelog.
• 0645930 3.6.1
• bac40ab Parse type applications correctly in Node.js 12. (#1643)
• e5919e4 Update .gitignore.
• 2099e72 3.6.0
• d45c5b8 Add 3.6.0 changelog.
• b8012f4 Update dependencies, plus the URLs for the GitHub repos and docs.
• 10c004f update docs with new template (#1604)
• aa0b6c1 switch to new-ish ECMAScript syntax
• 1546d40 update ESLint config
• 27f9a33 migrate from `babylon` to `@ babel/parser`
• d310908 Update ajv to the latest version 🚀 (#1599)

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.