Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I haven't used pwsh in a few years, but does `ConvertTo-Json` still have that terrible `-Depth` parameter that you have to remember to set so that it doesn't mangle your JSON? A quick web search indicates that it does.

Edit: Yes, it does.

    '{ "a": { "b": { "c": { "d": { "e": 5 } } } } }' | ConvertFrom-Json | ConvertTo-Json

    {
      "a": {
        "b": {
          "c": "@{d=}"
        }
      }
    }
So you have to remember to set `-Depth 100` for every invocation of `ConvertTo-Json`. You also can't set it higher because it has a hard-coded limit of 100, so hopefully you never deal with JSON that has more nesting than that.

Yeesh. I like PS, but this one commandlet's design has always baffled me.



That API is being reworked now at least https://github.com/PowerShell/PowerShell/pull/11198


I was wondering about that, because the docs say it uses Json.NET, which while an excellent library is being replaced with System.Text.Json in the BCL/FCL as far as I know.


Nu shell is also really handy for these types of format conversions (and querying):

  > echo '{ "a": { "b": { "c": { "d": { "e": 5 } } } } }' | from json | to toml
  [a.b.c.d]
  e = 5


Yep. Love powershell, disliked this decision, but now understand it: objects returned from native powershell commands have a loooooooooooooooooooot of nesting. Try:

  gci | select -first 1 | ConvertTo-Json -Depth 2
  gci | select -first 1 | ConvertTo-Json -Depth 3
  gci | select -first 1 | ConvertTo-Json -Depth 4
one at a time.


In the words of Raymond Chen, adding a `-Depth` parameter is using a global solution to a local problem. If certain types should not be serialized beyond a certain depth, the config should be per type, not on the whole serialization.

Or leave it as it is and expect the user to map the complex values into hashtables. Eg in your example, make the user pipe the objects through `%{ @{ Name = $_.Name; Mode = $_.Mode; } }` first.

In any case, I don't know about other PS users, but all my command-lines that ended with ConvertTo-Json either started with ConvertFrom-Json (transforming an existing JSON file), or started with HashTables (building a JSON file from scratch) or a mix of the two. Therefore I always wanted everything to be serialized, and the `-Depth` parameter was always a nuisance.


Thankfully it looks like -Depth is going to default to 64 when the cmdlet is ported to System.Text.Json, per voxic11 downthread: https://github.com/PowerShell/PowerShell/pull/11198


True, but isn't it a good idea to have an "upper limit" global value too in case of badly behaved types?


Why? Both JSON strings and their deserialized value's memory usage grows only linearly if you nest stuff (unless you're doing something dumb).

By that logic they should also add -MaxArrayLength to make the parser stop parsing long JSON arrays, -MaxProperties to make it only parse object properties up to a limit, -MaxStringLength to only make it parser strings up to a certain length...

It's completely pointless.


I suppose it is only a concern during serialization, not deserialization.


Yes, a limit per type. Not for the whole serialization.


But what if a type which you need to serialize wrongly doesn't set the limit?

EDIT: I see your point now, thank you for explaining


Again, I'm not saying there shouldn't be a default limit. I'm saying the limit should be per type, not for the whole serialization.

It can be something as trivial as "PSHashTable is allowed to serialize without limit. Every other type is limited to N levels, unless the user sets `$SERIALIZATION_LIMIT[System.Type]` to some other value." Or make the `-Depth` parameter a `Dictionary<System.Type, int>`.


It turns an object hierarchy into flat text. References in the object hierarchy can be circular, and the Depth parameter limits the infinite loop a circular reference would cause.


Detecting circular structures (sometimes just called graphs), is a solved problem. The Lisp reader and printer even serialize them correctly: #1=(42 . #1#) makes a pair of two items. The first item is a 42 and the second is the pair itself.

It sounds like whoever implemented this just didn't know what they were doing.


This can't happen. JSON does not have references.


I believe he’s referring to an arbitrary object being converted to JSON.

From-JSON wouldn’t have this concern, but to-JSON would


Yes. My mistake.


>var obj = {}; obj.foo = obj; JSON.stringify(obj);

>Uncaught TypeError: cyclic object value

If browser JS engines can detect circular references, the PS serializer can too.


it CAN, but it DOESN'T.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: