Wondering if a custom type SerializerSettings to encapsulate default 1024 maxDepth and false returnHashtable here would be better than adding overloads.

if there are other settings we would want in the future, then that would be a better approach

I would consider the option to set -Depth less than 0 for no maximum depth.
0 or $Null are often the result of a wrong calculation. Besides, 0 could technically still be a desired "depth".

@iRon7

Besides, 0 could technically still be a desired "depth".

How so? Wouldn't that mean you want the deserialization to always fail? Is that really a use case? Also, the underlying Newtonsoft.Json does not allow 0 or less as MaxDepth, it throws at runtime.

For a sample recurring hash table like:

$ht = @{
	Name = "Tree"
	Parent = @{
		Name = "Parent"
		Child = @{
			Name = "Child"
		}
	}
}
$ht.Parent.Child.Parent = $ht.Parent

A $ht | ConvertTo-Json -Depth 1 results in:

{
    "Parent":  {
                   "Child":  "System.Collections.Hashtable",
                   "Name":  "Parent"
               },
    "Name":  "Tree"
}

I was expecting for $ht | ConvertTo-Json -Depth 0 to result in:

{
    "Parent":  "System.Collections.Hashtable",
    "Name":  "Tree"
}

But I indeed get an error:

ConvertTo-Json : Cannot validate argument on parameter 'Depth'. The 0 argument is less than the minimum allowed range
of 1. Supply an argument that is greater than or equal to 1 and then try the command again.
At line:1 char:29

• $ht | ConvertTo-Json -Depth 0

•                         ~
  

  • CategoryInfo : InvalidData: (:) [ConvertTo-Json], ParameterBindingValidationException
  • FullyQualifiedErrorId : ParameterArgumentValidationError,Microsoft.PowerShell.Commands.ConvertToJsonCommand

Anyways, wouldn't it be better to get either a completely flat output or an error in case of a (incorrect calculated/unassigned/mistyped variable) Depth of 0 or $Null?
I think a negative Depth would just be more knowingly chosen.
In other words, I do not really expect it to be a desired used case, but in the case of a scripting failure, I think a flat result or an error is more clear then a possible performance issue.

Just a thought, the decision is up to you...

I'm still of the opinion that unlimited is not needed. 1 to int32.MaxValue is sufficient. Any JSON over Int32.MaxValue is either broken or contrived.

In the real world, I expect the default of 1024 to be sufficient, so I would be ok with not needing unlimited. -Depth 0 for only the top level makes sense and consistent with Get-ChildItem -Depth 0

@iRon7 after thinking it through, I agree a negative value might be better than 0.

@markekraus I understand powershell needs to be secure by default but I think this is an opportunity to provide the option for people to just say "I know what I'm doing, get out of my way". Sure, you could have them type -Depth:([int]::MaxValue), but feels less convenient in my opinion and it would still have the overhead (however small) of the serializer repeatedly checking to make sure max depth isn't exceeded (not the case if you pass null).

What do you guys think of having -Depth -1 for unlimited and maybe throw an error on BeginProcessing() if -Depth is 0?

It's not about security.. it's about absurdity. The only JSON objects that are that deep are contrived (made to be deep for fun or to specifically test depth limits) or broken (whatever produced the JSON had some issue). 1024 is already absurdly deep for a JSON object. We all ready catch outliers with the default setting. Between 1024 and Int32.MaxValue is a the realm of intrigue only. We don't need to have special case logic for that. We don't even really need infinite depth. What is the target audience for such a feature? Who really has objects that deep?

Just because we can, doesn't mean we should I still stand by my statement that 1 to int32.MaxValue is sufficient.