Description

• Closes Snapshots do not render completely anymore since 4.1.1 #9964
• Follow up to fix(pretty-format): limit output for large object #9949

Previous approach's single outputLength counter had an issue that it over counts deeper children multiple times due to tree structure. Pictoricaly it looks like:

total output: [================================================================]

depth 1:      [==========A==========]  [==========B==========]  [=====C=====]
depth 2:      [=a1=] [=a2=] [=a3=]     [==b1==] [==b2==]        [=c1=]
depth 3:      [x][y]  [z]              [p] [q]                   [r]

A different idea in this PR is to accumulate print length per depth and trigger maxDepth = 0 bail out at any depth. And this is indeed what Node actually does https://github.com/nodejs/node/blob/61102cdbb3d59155ad5bb4fc9419627a31e63f7a/lib/internal/util/inspect.js#L1486-L1498 (My last agent research note said this but I totally overlooked 🤦)

However notably neither of approach is an exact total length tracking and they are only heuristics that get skewed by input object's nesting structure and depth factor. Rough estimation of length limit guarantee is

• PR 9949: Actual format length limit ~= maxOutputLength / Average depth
  • This is because the output of children at depth n contributes to outputLength counter for n times
• This PR: Actual format length limit ~= maxOutputLength * Average depth
  • This is because outputLengthPerDepth is per depth accumulation.

I'm not entirely sure the practical impact between two, so this is entirely an educated guess, but this PR has chosen the 2nd approach instead of bumping up limit with 1st approach.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.
• Please check Allow edits by maintainers to make review process faster. Note that this option is not available for repositories that are owned by Github organizations.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.