@iSazonov Thank you for the thorough review!
I've pushed a commit (b37e6ae) addressing your feedback. Replying to each thread with details.

Summary

All requested changes have been implemented and tested.

*DateTime test fails due to timezone (existing issue, not related to this PR)

Commits to push

*DateTime test fails due to timezone (existing issue, not related to this PR)

Could you please point the test in new issue?

*DateTime test fails due to timezone (existing issue, not related to this PR)

Could you please point the test in new issue?

@iSazonov This was a local environment issue on my machine. I shouldn't have mentioned it. Sorry for the confusion.

As @iSazonov suggested:

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.

Implemented RawObjectWrapper approach (aa9a89f):

1. Entry point now branches on objectToProcess is PSObject:

   • PSObject → JsonConverterPSObject (Extended/Adapted properties)
   • Raw object → RawObjectWrapper + JsonConverterRawObject (Base properties only)

2. Both converters share similar structure for easy future removal when STJ gains needed extensions.

Removed hardcoded type list:

With the raw/PSObject distinction in place, IsPrimitiveType (hardcoded list of DateTime, Guid, Uri, etc.) is no longer needed. Replaced with IsStjNativeScalarType() which dynamically detects if STJ natively serializes a type as scalar by invoking STJ and checking if result starts with { or [. Results are cached per type. This automatically adapts to future .NET/STJ type additions (DateOnly, TimeOnly, etc.).

STJ limitation workarounds (not a type list):

• BigInteger: STJ serializes as object, but JSON standard expects number
• Infinity/NaN: STJ throws, but V1 serializes as string

Test Results:

• Pester V2: 5/5 passed
• Pester Common: 31/33 passed (1 DateTime timezone issue, 1 pending)
• xUnit: 5/5 passed

@iSazonov Thank you for the suggestion. I've unified JsonConverterPSObject and JsonConverterRawObject by adding a basePropertiesOnly flag to JsonConverterPSObject. Now JsonConverterRawObject simply delegates to JsonConverterPSObject with basePropertiesOnly: true, eliminating the duplicated code.

This approach reduces the code by ~120 lines while maintaining the same behavior. Removing RawObjectWrapper in the future will also be straightforward.

Commit: 385cf51

@yotsuda Thanks for your efforts!

I was thinking about how we could use all the features of STJ and circumvent its limitations. The stumbling block is actually in the JsonConverter.TryWrite(). It is internal method which we cannot change.
I decided to ask Google AI, it confirmed this limitation, but after my tricky questions, it finally suggested a workaround.
There are two ideas there:

1. Use a tier off class (closure) to track the current depth.
2. Use custom Modifier to "reset" the object's properties when the maximum depth is reached.

If you have the time and desire, try whether this hike works.

using System.Text.Json;
using System.Text.Json.Serialization.Metadata;

public class DepthLimiter
{
    private int _currentDepth = 0;
    private readonly int _maxDepth;

    public DepthLimiter(int maxDepth) => _maxDepth = maxDepth;

    // This modifier is the logic that will be cached
    public void Modifier(JsonTypeInfo typeInfo)
    {
        if (typeInfo.Kind != JsonTypeInfoKind.Object) return;

        foreach (var property in typeInfo.Properties)
        {
            var originalGet = property.Get;
            if (originalGet == null) continue;

            property.Get = (obj) =>
            {
                // Increment depth as we descend into a property
                _currentDepth++;
                try
                {
                    if (_currentDepth > _maxDepth) return null; // Graceful stop
                    return originalGet(obj);
                }
                finally
                {
                    _currentDepth--; // Decrement as we unwind
                }
            };
        }
    }
}

// Usage for Dynamic Objects
var limiter = new DepthLimiter(3);
var options = new JsonSerializerOptions
{
    TypeInfoResolver = new DefaultJsonTypeInfoResolver
    {
        Modifiers = { limiter.Modifier }
    }
};

string json = JsonSerializer.Serialize(dynamicObject, options);

@iSazonov Thank you for the interesting suggestion! I tested the DepthLimiter approach with JsonTypeInfoResolver.Modifiers.

Test Results

I created a tracing version to observe how property.Get is called:

Object structure: L0 -> Child -> L1 -> Child -> L2

Trace output:
  Name: enter=1, exit=1   <- L0.Name
  Child: enter=1, exit=1  <- L0.Child
  Name: enter=1, exit=1   <- L1.Name (expected depth=2)
  Child: enter=1, exit=1  <- L1.Child (expected depth=2)
  Name: enter=1, exit=1   <- L2.Name (expected depth=3)
  Child: enter=1, exit=1  <- L2.Child (expected depth=3)

Problem

The property.Get modifier is called per property access, not per object level:

1. Name and Child are siblings at the same level → both get depth=1
2. After getting Name, depth decrements back to 0
3. When getting Child, depth increments to 1 again (not 2)
4. Properties inside nested objects also start at depth=1

This means the modifier cannot track object nesting depth - it only tracks individual property accesses which are independent of each other.

Conclusion

The DepthLimiter approach doesn't work for limiting serialization depth because STJ's property.Get hook operates at the wrong granularity. It intercepts property value retrieval, but not the object hierarchy traversal.

The current JsonConverter-based approach with explicit depth tracking in Write() remains the correct solution - it hooks into the actual serialization traversal where we can properly track object nesting levels.

@iSazonov To be honest, I've been using AI to submit and improve
this PR from the beginning - reading issues, reproducing bugs,
writing tests, modifying code, building, running git commands,
and drafting/posting the PR.

This might disappoint you in some ways. But I believe this solution
could help people around the world rediscover the value of PowerShell.

https://github.com/yotsuda/PowerShell.MCP

I'd appreciate your feedback - and your advice on some technical
limitations that might benefit from enhancements in PowerShell itself.

GitHub

GitHub - yotsuda/PowerShell.MCP: Enables AI assistants (such as Claude Desktop) to execute PowerShell commands and CLI tools within a persistent PowerShell console. Supports Windows, Linux, and macOS.

Enables AI assistants (such as Claude Desktop) to execute PowerShell commands and CLI tools within a persistent PowerShell console. Supports Windows, Linux, and macOS. - yotsuda/PowerShell.MCP

@yotsuda It's very good that you can use AI tools to create code more quickly and efficiently!

Since our iterations involve STJ more and more at each step, I assumed that there was a way to circumvent its limitations.
I had no idea how STJ worked inside. With the help of AI, I received an explanation that the object properties are iterated through in ObjectConverter and it performs recursive calls. It also performs depth control in its internal Write method. In fact, only converters have access to CurrentDepth.
Thus, the only way for us is to create custom converters.
Of course, it doesn't make sense to recreate all the converters. The best solution would be to make a universal wrapper for them (we cannot overload its internal Write method!). Actually, we were moving along this path.
I think I've managed to find another option that looks very elegant. (Of course, this requires some further refinement.)

using System.Text.Json;
using System.Text.Json.Serialization;
using System.Text.Json.Serialization.Metadata;

/// <summary>
/// A high-performance factory that truncates JSON serialization at a specific depth
/// by writing the object's .ToString() value instead of recursing deeper.
/// </summary>
public class TruncatingConverterFactory : JsonConverterFactory
{
    private readonly int _maxDepth;
    private JsonSerializerOptions? _bypassOptions;

    public TruncatingConverterFactory(int maxDepth)
    {
        _maxDepth = maxDepth;
    }

    public override bool CanConvert(Type typeToConvert)
    {
        // Use System.Text.Json's internal classification to target only "compound" types.
        // This skips primitives, strings, and simple leaf values (DateTime, Guid, etc.) automatically.
        var typeInfo = JsonSerializerOptions.Default.GetTypeInfo(typeToConvert);
        
        return typeInfo.Kind switch
        {
            JsonTypeInfoKind.Object     => true,
            JsonTypeInfoKind.Enumerable => true,
            JsonTypeInfoKind.Dictionary => true,
            _                           => false 
        };
    }

    public override JsonConverter CreateConverter(Type typeToConvert, JsonSerializerOptions options)
    {
        // Create a single bypass options instance to resolve 'default' converters.
        // This avoids infinite recursion and ensures we reuse the metadata cache for default logic.
        if (_bypassOptions == null)
        {
            var clone = new JsonSerializerOptions(options);
            // Remove THIS factory from the clone to find the original intended converter
            for (int i = clone.Converters.Count - 1; i >= 0; i--)
            {
                if (clone.Converters[i] is TruncatingConverterFactory)
                    clone.Converters.RemoveAt(i);
            }
            _bypassOptions = clone;
        }

        // Get the default converter (POCO, Array, or Dictionary converter) from the bypass cache
        JsonConverter defaultConverter = _bypassOptions.GetConverter(typeToConvert);

        // Instantiate the generic wrapper that handles the depth logic
        return (JsonConverter)Activator.CreateInstance(
            typeof(DepthLimitedConverter<>).MakeGenericType(typeToConvert),
            _maxDepth, 
            defaultConverter)!;
    }

    private class DepthLimitedConverter<T> : JsonConverter<T>
    {
        private readonly int _maxDepth;
        private readonly JsonConverter<T> _defaultConverter;

        public DepthLimitedConverter(int maxDepth, JsonConverter defaultConverter)
        {
            _maxDepth = maxDepth;
            _defaultConverter = (JsonConverter<T>)defaultConverter;
        }

        public override void Write(Utf8JsonWriter writer, T value, JsonSerializerOptions options)
        {
            // writer.CurrentDepth is the source of truth for the current position in the tree.
            if (writer.CurrentDepth >= _maxDepth)
            {
                // Graceful stop: write the string representation instead of recursing
                writer.WriteStringValue(value?.ToString() ?? "null");
                return;
            }

            // High-speed bypass: use the cached internal converter to continue normal serialization
            _defaultConverter.Write(writer, value, options);
        }

        public override T Read(ref Utf8JsonReader reader, Type typeToConvert, JsonSerializerOptions options)
        {
            // Fallback for deserialization
            return _defaultConverter.Read(ref reader, typeToConvert, options);
        }
    }
}

Usage:

private static readonly JsonSerializerOptions _options = new()
{
    WriteIndented = true,
    Converters = { new TruncatingConverterFactory(maxDepth: 3) }
};

public string SerializeWithLimit(object data)
{
    // The factory will now truncate any branch reaching depth 3
    return JsonSerializer.Serialize(data, _options);
}

Summary of Changes

Commit: 6913cb119

Test Results (Start-PSPester)

Original comment: #26637 (comment)

@iSazonov Thank you for sharing this insight! The TruncatingConverterFactory approach is elegant for general-purpose depth limiting. Our JsonConverterPSObject uses a similar pattern with writer.CurrentDepth for depth tracking (ConvertToJsonCommandV2.cs#L329), but with PSObject-specific handling (ETS properties, hidden properties, etc.) that wouldn't be possible with a generic wrapper around STJ's default converters.

Our JsonConverterPSObject uses a similar pattern with writer.CurrentDepth for depth tracking (ConvertToJsonCommandV2.cs#L329), but with PSObject-specific handling (ETS properties, hidden properties, etc.) that wouldn't be possible with a generic wrapper around STJ's default converters.

With approach we will still use all our custom converters you created in the PS, mainly PSObject converter where psobject magic is contained.
As result we have no need to use manual wrapping for raw objects for custom property enumeration and recursion. So we will benefit from all STJ features including cache.

So our solutions will contain 3 small parts:

1. Magic converter factory for wrapping standard and third-party converters. (Here we do depth control as we need.)
2. PSObject custom converter.
3. Our PS specific converters

@iSazonov Thank you for the architectural suggestion. I created prototypes to validate each of the three components you proposed.

1. Magic Converter Factory (for depth control)

What is "STJ cache"?

STJ provides caching at two levels:

1. Converter cache: For JsonConverterFactory, STJ caches CreateConverter results per type
2. JsonTypeInfo cache: Property metadata including optimized property accessors

Your proposal aims to leverage the JsonTypeInfo cache by using STJ's default serialization. Let me share what I found.

Finding

STJ's default serialization via TypeInfo works:

var options = new JsonSerializerOptions { TypeInfoResolver = new DefaultJsonTypeInfoResolver() };
var typeInfo = options.GetTypeInfo(typeof(TestNode));
JsonSerializer.Serialize(obj, typeInfo);  // OK

However, V1-compatible depth control cannot be added while using STJ's default serialization:

I verified V1 behavior:

PS> @{L0=@{L1=@{L2=@{L3="deep"}}}} | ConvertTo-Json -Depth 2 -Compress
{"L0":{"L1":{"L2":"System.Collections.Hashtable"}}}

V1 outputs ToString() when depth exceeded. STJ's MaxDepth throws an exception instead. To maintain V1 compatibility, we must use a custom converter that manually enumerates properties.

Even without V1 compatibility

Even if we drop V1 compatibility, delegating raw objects to STJ native serialization loses depth control entirely—STJ serializes the full object graph. Depth control requires custom converters regardless of V1 compatibility.

Comparison

Note: Both approaches use reflection for property enumeration—the difference is whether it goes through PowerShell's adapter system or directly calls Type.GetProperties().

Conclusion

❌ Not recommended. The primary goal—utilizing STJ's JsonTypeInfo cache—cannot be achieved because depth control requires custom property enumeration. Without that benefit, Magic Converter Factory only eliminates wrapper allocation while adding the complexity of a generic factory pattern.

2. JsonTypeInfo for PSObject (dynamic property handling)

Finding

var typeInfo = options.GetTypeInfo(typeof(PSObject));
Console.WriteLine($"Properties: {typeInfo.Properties.Count}");
// Output: 6 (BaseObject, Members, Properties, Methods, TypeNames, ImmediateBaseObject)

JsonTypeInfo.Properties returns type-level static properties, not instance-level dynamic properties. Since JsonTypeInfo is cached per type, it cannot handle PSObject's instance-specific dynamic properties from Add-Member/ETS.

Conclusion

❌ Not feasible. Custom JsonConverter<PSObject> is required.

3. PS-specific Converters

✅ Already implemented: JsonConverterBigInteger, JsonConverterDouble, JsonConverterFloat, JsonConverterNullString, JsonConverterDBNull, JsonConverterInt64Enum, JsonConverterJObject.

Summary

The key constraint is that depth control requires custom converters with manual property enumeration, which prevents JsonTypeInfo cache utilization. Given this, I believe the current implementation is the right approach.

@yotsuda Thanks for your investigations!

Your proposal aims to leverage the JsonTypeInfo cache by using STJ's default serialization. Let me share what I found.

No. Suggestion is to use factory.

The code sample I shared is not ready to test. It is only demo code.
We would need to refine this factory to get it work.
Have you a test branch for CovertTo-Json with the approach?

@iSazonov Thank you for the suggestion! I've implemented the JsonTypeInfoKind approach for type classification.

Commit: 2ecc51e

Changes

1. Use JsonTypeInfoKind for type classification (eliminates "extra serialization"):

return s_stjNativeScalarTypeCache.GetOrAdd(type, static t =>
{
    var typeInfo = JsonSerializerOptions.Default.GetTypeInfo(t);
    return typeInfo.Kind == JsonTypeInfoKind.None;
});

2. Added JsonConverterType for System.Type:
   • STJ reports JsonTypeInfoKind.None for System.Type but cannot serialize RuntimeType
   • New converter with CanConvert override handles all Type-derived types
   • Serializes as AssemblyQualifiedName string (V1 compatibility)

Test Results

• V2-specific tests: 5/5 passed ✅
• Common tests: 36/37 passed ✅ (DateTime timezone is existing issue)

TruncatingConverterFactory Investigation

I also investigated the TruncatingConverterFactory approach you proposed. I created a test branch to evaluate it:

Test branch: https://github.com/yotsuda/PowerShell/tree/feature-convertto-json-factory-test

Results

Root Cause

The Factory approach delegates nested raw objects to STJ's default converter via _defaultConverter.Write(). This causes issues with types like FileInfo:

1. STJ's ObjectConverter uses .NET reflection directly, not PSObject property enumeration
2. Types like FileInfo have deep/circular reference structures (Directory.Parent.Root...) that STJ's default serialization cannot handle properly
3. The result is empty objects {} instead of the expected 17 properties

The current implementation uses RawObjectWrapper + JsonConverterPSObject(basePropertiesOnly: true) to ensure all nested objects go through PSObject property enumeration, which correctly handles these cases.

Conclusion

While the Factory pattern is elegant for pure STJ scenarios, PowerShell's requirement to use PSObject property enumeration (instead of direct .NET reflection) makes it incompatible with delegating to STJ's default converters for nested objects.

GitHub

GitHub - yotsuda/PowerShell at feature-convertto-json-factory-test

PowerShell for every system! Contribute to yotsuda/PowerShell development by creating an account on GitHub.

@iSazonov Thank you for the review!

Code Duplication - Refactoring Done

I've unified the duplicate code as you suggested. The changes:

1. SerializeEnumerable - Unified to use WriteValue

Before (13 lines):

foreach (var item in enumerable)
{
    if (item is null) { writer.WriteNullValue(); }
    else if (item is PSObject psoItem) { Write(writer, psoItem, options); }
    else { JsonSerializer.Serialize(writer, new RawObjectWrapper(item), ...); }
}

After (1 line):

foreach (var item in enumerable)
{
    WriteValue(writer, item, options);
}

2. WriteProperty - Unified to use WriteValue

Removed duplicate branching logic (scalar check, PSObject check, RawObjectWrapper) and delegated to WriteValue().

3. WriteValue - Added AutomationNull handling

Moved LanguagePrimitives.IsNull() check to WriteValue(), eliminating the duplicate null check in WriteProperty().

Result: -30 lines (7 insertions, 37 deletions)

Why SerializeDictionary and SerializeAsObject remain separate

These methods have fundamentally different purposes that prevent unification:

They operate on different data structures (dictionary entries vs PSObject properties), so unification would add complexity rather than reduce it.

Why Write and WriteValue remain separate

Write is the JsonConverter entry point with PSObject-specific logic (depth limiting, Extended properties handling). WriteValue routes arbitrary values - for PSObject it calls Write, for raw objects it wraps with RawObjectWrapper. Merging them would create circular calls or require restructuring the converter architecture.

Test Results

• V2 specific tests: 5/5 passed ✅
• Common tests: 36/37 passed (1 failure is existing DateTime timezone issue) ✅

JsonConverterType V1 Behavior

V1 Code Path

V1 has no special handling for System.Type. It relies on Newtonsoft.Json's default behavior:

1. JsonObject.cs#L510: JsonConvert.SerializeObject(preprocessedObject, jsonSettings)
2. Newtonsoft.Json serializes System.Type by calling ToString(), which returns AssemblyQualifiedName

There is no explicit System.Type handling in V1 code - it's purely Newtonsoft.Json's default behavior.

V1 vs V2 Output Comparison

# Both V1 and V2 produce identical output:
(Get-PSProvider FileSystem).ImplementingType | ConvertTo-Json -Compress
# → "Microsoft.PowerShell.Commands.FileSystemProvider, System.Management.Automation, ..."

Why JsonConverterType is needed in V2

STJ (System.Text.Json) cannot serialize System.Type by default and throws:

System.NotSupportedException: Serialization and deserialization of 'System.Type' instances is not supported.

So JsonConverterType explicitly writes AssemblyQualifiedName to match V1 behavior.

Test coverage

The existing test in ConvertTo-Json.Tests.ps1 covers PSProvider serialization, which includes ImplementingType (Context: "ConvertTo-Json with PSObject").

@yotsuda Thanks! Now the code looks better.

I looked test branch for factory approach. and I think it can work, and I believe it will be our final result that we will come to.
Of course, improvements are needed there. The main problem there now is that the default converter is always called. But the factory is the dispatcher that must return the correct converter, and this is not always the default converter. So for the dictionary and enumeration, it should return the corresponding converters, which should be created based on the methods that we already have. For composite objects, use our raw converter (it will be linked to this type in the cache!), no pre-wrapping is required (it will be inside the converter for manual enumeration of properties). Finally, the default converter is returned for primitive types.

I think we should do a few more iterations here before we get an idea of how to make the factory in the right way.

From the very beginning, my idea was to maximize the capabilities of the standard serializer and transfer processing to custom converters. We have now completed part of this journey.

In the next iteration, I suggest thinking about implementing custom converters for dictionary and enumeration.
Now we have methods for them, but I suppose it could be converters. (And re-use them in factory later.)

The existing test in ConvertTo-Json.Tests.ps1 covers PSProvider serialization, which includes ImplementingType (Context: "ConvertTo-Json with PSObject").

Cannot find. Could you please share link to the test?