I think intention is to use the cmdlet in pipeline. In the case all objects coming from pipeline already wrapped in PSObject.

Or it is single way the serializer can work?

You're right that pipeline objects are already wrapped. However, -InputObject parameter objects are not:

$hash | ConvertTo-Json             # $hash is wrapped in PSObject
ConvertTo-Json -InputObject $hash  # $hash is NOT wrapped

PSObject.AsPSObject() is cheap (returns same object if already wrapped), so it handles both cases safely.

As soon as STJ is extended so that we can use the standard serializer, we can reconsider this.

If we will process raw objects as raw objects (that is discussed in another comment) we should do the same in the point too.

The entry point wraps input with PSObject.AsPSObject() (L213). Raw vs PSObject distinction is handled in nested object serialization via Option C implementation (WriteProperty and WriteValue check value is PSObject).

Here we should keep V1 InputObject behavior - process the object as raw.

Really we need two things - serialize PSObject and serialize raw object.
Due to the limitations of the standard serializer we cannot use it directly for serializing raw objects.
So we have to use custom reflection by means of wrapping to PSObject.
But we still have to distinguish whether the object was raw or originally PSObject.

I suggest using a simple trick - to wrap the raw object in a new auxiliary class and create a separate converter for it. Both converters will be able to re-use the same code with one difference when handling special properties.

Alternatively, we could add some flag to the PSObject instance and use one converter, but its code will be more complicated, but the main thing is if we get STJ with the extensions we need, we'll just delete the new auxiliary class and its converter without massive code change.

Can we use:

            foreach (var prop in pso.Properties)

pso.Properties returns both Extended and Adapted properties. The current code filters by memberTypes to support -ExcludeBaseProperties, which needs Extended-only when $true.

From my understanding every instance of JsonSerializerOptions keep its own type cache. If it is true it makes sense to cache JsonSerializerOptions instances per psrunspace. The lazy cache need two parameter -compressOutput and stringEscapeHandling.

Good point. Caching JsonSerializerOptions per runspace would improve performance. However, this requires architectural changes (runspace-level state management) that I think are beyond the scope of this PR. I'd like to address this in a follow-up PR if you agree.

We can address this later.

Acknowledged. Will address JsonSerializerOptions caching in a future PR.

Why do we check LanguagePrimitives.IsNull(obj)? I don't see this in V1 code.
Will this change PSCustomObject processing?

The LanguagePrimitives.IsNull() check handles AutomationNull.Value in addition to regular null. This is needed because PowerShell pipeline can produce AutomationNull.Value which should be serialized as JSON null. V1 handles this differently through Newtonsoft's converters. This doesn't change PSCustomObject processing - it only affects null-like values.

What is a scenario for the check?

The check handles AutomationNull.Value when it becomes the BaseObject of a PSObject.

In C#, obj is null returns false for AutomationNull.Value (it's a singleton object), but LanguagePrimitives.IsNull(obj) returns true.

Scenario:

 = [System.Management.Automation.Internal.AutomationNull]::Value
 = [PSObject]::AsPSObject()
.BaseObject -eq   # True
 | ConvertTo-Json          # Output: null

Without this check, AutomationNull.Value would be serialized as an object instead of null.

See: L266

AutomationNull is for Engine only. AutomationNull is intended for internal use only in the pipeline for null transmission. This should not be used explicitly.

Should we take into account if source object is raw or PSObject? My concern the wrapping will add extra properties (extended and adapted).
The question is for all place where we use the pattern.

I understand the trick as replacing reflection in standard STJ API with PSObject reflection.
Perhaps we should add specific property to the PSObject to indicate raw object and take it into account in PSObject converter to add or don't add extended/adapted properties.

This also assume that while we enumerating PSObject proprties we can check its kind and check for JsonIgnore.

I tested several scenarios and the current implementation appears to serialize only the actual properties without adding extra Extended/Adapted properties. However, I may be missing edge cases. Please let me know if you see different behavior - I'd be happy to investigate further.

I compare outputs for FileInfo object in V1 version - 1. pipeline and 2.InputObject - they are different. What is result for V2? Also we could check a class with FileInfo property.

Thank you for the feedback. I investigated the V1 vs V2 behavior in detail.

Summary of Findings

Direct serialization (Guid, IPAddress)

V1 issues: Pipeline vs InputObject produces different output for Guid and IPAddress.

V2 resolves these inconsistencies - Pipeline and InputObject produce identical output.

FileInfo as a class property

class TestClass { [System.IO.FileInfo]$File }
$obj = [TestClass]::new()
$obj.File = Get-Item $env:windir\notepad.exe  # or [FileInfo]::new(...)
$obj | ConvertTo-Json -Depth 2

V1: Always outputs Base properties only (17) because Newtonsoft.Json uses direct .NET reflection on nested objects.

V2: Outputs Base (17) + Adapted (7) + Extended (0-6), depending on whether the object was PSObject-wrapped.

Possible Approaches

Approach A: The current V2 implementation uses a hardcoded IsPrimitiveType list (Guid, DateTime, Uri, BigInteger, etc.). This is not ideal for long-term maintenance as new .NET types require manual updates.

Approach C: I found we can use existing mechanisms to replace the hardcoded list:

1. Check item is PSObject before calling PSObject.AsPSObject() to decide whether to include Extended properties
2. Use MemberType to identify property categories:

Question

Which approach would you prefer?

• A: Keep current behavior (accept hardcoded list for now)
• B: Use Base only (V1 compatible, but loses Adapted props like Mode, VersionInfo)
• C: Implement raw vs PSObject tracking (replaces hardcoded list, partial V1 compatibility)

We should preserve V1 capability:

1. allow users to serialize raw objects with InputObject parameter
2. serialize nested objects (property values) as raw object without adding extra properties.

It is C option.

Done in fdbe94ae6. Implemented Option C:

• value is PSObject → Serialize with Extended | Adapted properties
• Raw .NET object → Serialize with Base properties only (V1 compatible)

Key changes:

• WriteValue L478-L489: checks value is PSObject
• WriteProperty L664-L677: checks value is PSObject
• SerializeRawValue L499-L539: new method for raw objects
• AppendBaseProperties L589-L611: filters to MemberType == Property

V1 compatibility verified:

Why do we need a specific processing here? Why not delegate the value processing to PSObject serializer?

The maxDepth == 0 check converts non-primitive values to strings, which is V1-compatible behavior for depth limiting. If we delegated to the PSObject serializer without this check, it would attempt full serialization and fail the depth check later. Handling it here provides better control and matches V1 behavior.

With implementing option C I believe it will be changed. I'd still expect we do generic processing. V1 version does recursion here.

Done in fdbe94a. The maxDepth == 0 handling works with Option C. See WritePropertyRaw L616-L642 which handles recursion via SerializeRawValue.

Enumerating properties in PSObject is reflection. So one more check is not add more problems.

Done in 0e07b33. Added JsonIgnoreAttribute check in ShouldSkipProperty. For PSProperty backed by MemberInfo, we now check for the attribute.

nit: Maybe check NewtonSoft attribute too? We need discuss.

Currently only checking System.Text.Json.Serialization.JsonIgnoreAttribute: L694-L700

Question: Should we also check Newtonsoft.Json.JsonIgnoreAttribute for backward compatibility? V1 uses Newtonsoft, so users may have decorated their classes with that attribute.

If we will process raw objects as raw objects (that is discussed in another comment) we should do the same in the point too.

What is a scenario for the check?

Do you mean we have a breaking change with the scenario?

Since we use Compress we can explicitly compare with {"2":"two","1":"one"}.
I suggest use the pattern in (all) other tests too. It is more reliable and more readable. It is true for "-Not -Throw" - it is better replace its with such "positive" tests if possible.

AutomationNull is for Engine only. AutomationNull is intended for internal use only in the pipeline for null transmission. This should not be used explicitly.

Please use the same pattern everywhere. See line 450 and 760.

In the context (how we use it) I'd rename to isNotNull or reverse to bool isNull = true;