Summary of the proposal:

• Remove the default value for -Depth

  • The hard-coded internal limit of 100, which when exceeded, reports an error, is sufficient to prevent "runaway" JSON strings stemming from object trees with cyclic dependencies.
  • Typical input objects will then be fully serialized by default, which is typically the intent.

• Use -Depth solely at the user's discretion in order to:

  • Intentionally truncate the input object tree at the specified depth.
  • On rare occasions, allow serialization of object trees that are deeper than 100 levels (this could also be a solution to In ConvertTo-Json the max allowed depth is 100. However, we should add code to dynamically check if we are running out of stack, and serialize objects with bigger depths. #3181).

Motivation

-Depth defaulting to 2 in ConvertTo-Json has caused much confusion and frustration over the years; @iRon7 has recently tried to create a "canonical" post on SO, which also shows how frequently the issue is arising.

Currently, an input object tree that exceeds the (default) depth doesn't cause an error, but results in near-useless .psobject.ToString() serialization of property values that exceed the depth (see #8381 for a proposal to visualize the cut-off differently).

In combination with the low default -Depth value of 2, that makes for frequent user frustration, because the behavior frequently amounts to quiet de-facto failure that may not be discovered until later.

The seemingly arbitrary and quiet truncation is surprising to most users, and having to account for it in every ConvertTo-Json call is an unnecessary burden.

Backward-compatibility impact

The only way in which I think existing code could be impacted is in that payloads generated with ConvertTo-Json could now increase in depth (and size), if users previously relied on the implicit cut-off at depth 2 - that strikes me as a Bucket 3: Unlikely Grey Area change.