build(deps-dev): bump tape from 5.4.0 to 5.6.3

[dependabot]

Bumps tape from 5.4.0 to 5.6.3.

Changelog

Sourced from tape's changelog.

v5.6.3 - 2023-01-15

v5.6.2 - 2023-01-15

Fixed

• [New] bin/tape: add --ignore-pattern flag [#586](https://github.com/ljharb/tape/issues/586)

Commits

• [eslint] fix indentation b035590
• [meta] add auto-changelog b467b85
• [eslint] enforce no-use-before-define 87deb68
• [eclint] fix editorconfig ce81cbe
• [eslint] clean up config a bit 3171edd
• [Tests] stackTrace: use the common getDiag utility 65df5a4
• [Fix] throws: avoid crashing on a nonconfigurable or nonextensible expected 0cd7a2c
• [meta] fix repo URLs 85d86a4
• Revert "[Tests] handle a broken error cause in node 16.9/16.10" 775ba37
• [meta] use npmignore to autogenerate an npmignore file 1645abb
• [eslint] enable func-style 75c0c3a
• [actions] update rebase action b3d724e
• [Deps] update array.prototype.every, deep-equal, string.prototype.trim e9c9aba
• [Deps] update defined, minimist, resolve 83695c0
• [Deps] update deep-equal, object-inspect 09906f3
• [Dev Deps] update @ljharb/eslint-config, aud afd8f64
• [Dev Deps] update array.prototype.flatmap 8b8bf07
• [Dev Deps] update aud f0fe7c0
• [Dev Deps] update tap-parser 2f61eac
• Merge tag 'v4.16.1' 96ff863
• [readme] fix version badge 20ea48d

v5.6.1 - 2022-09-19

Commits

• [eslint] fix indentation 2151e06
• [meta] add auto-changelog 86cbbd1
• [eslint] enforce no-use-before-define f8a8a7f
• [meta] fix repo URLs a9ae3c2
• [Tests] stackTrace: use the common getDiag utility 298cb80
• [eslint] enable func-style 98b9623
• [New] bin/tape: include the exact arg when there are no glob results; use require on --require files 6a1ce43
• [eslint] clean up config a bit 67ad201
• [meta] create FUNDING.yml 5b4752f
• [Refactor] bin/tape: make it a bit more functional, for easier v5 backporting fbdbfc9
• [Deps] update glob, object-inspect, resolve, string.prototype.trim 6a3c200
• [Dev Deps] update @ljharb/eslint-config, array.prototype.flatmap, es-value-fixtures, falafel 934d49b
• [Tests] fix no_only tests on Windows f35f71b
• Revert "[Tests] handle a broken error cause in node 16.9/16.10" 23fac16

... (truncated)

Commits

• 23aa477 v5.6.3
• 40f6ad3 v5.6.2
• 0cd7a2c [Fix] throws: avoid crashing on a nonconfigurable or nonextensible expected
• 09906f3 [Deps] update deep-equal, object-inspect
• afd8f64 [Dev Deps] update @ljharb/eslint-config, aud
• 8c9fe8e [New] bin/tape: add --ignore-pattern flag
• e9c9aba [Deps] update array.prototype.every, deep-equal, string.prototype.trim
• 8b8bf07 [Dev Deps] update array.prototype.flatmap
• b3d724e [actions] update rebase action
• 83695c0 [Deps] update defined, minimist, resolve
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

_{Mention [stepsize] in a comment if you'd like to report some technical debt. See examples here.}

[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: 2

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 detected.
• 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.