Context and request
Two defects make Json unsafe for its most obvious use case — reading a JSON file, changing a value, and writing it back. Both were reproduced locally against main.
Export-Json -Depth is silently inconsistent: it defaults to 2 and is only honoured on the -Compact path, because the pretty path delegates to Format-Json, which hard-codes -Depth 100. The same command therefore truncates nested objects to strings like "@{l4=deep}" with -Compact and preserves them without it.
Import-Json adds a _SourceFile note property to every object it returns. Any import, modify, export round-trip writes that property into the output file. examples/General.ps1 Example 18 demonstrates exactly this sequence and would produce a polluted file.
Scope
In scope: depth handling across Format-Json and Export-Json, and the provenance property added by Import-Json.
Out of scope: the pipeline-overwrite semantics of Export-Json, which are documented and intentional, and any change to Format-Json's indentation engine.
Aggregate acceptance criteria
- A JSON file imported and re-exported without modification produces structurally equivalent content.
Export-Json -Depth <n> produces the same nesting depth with and without -Compact.- Nothing that
Import-Json returns carries a property that was not present in the source document.
- Regression tests cover both behaviours and fail against the current implementation.
Technical decisions
Both are corrections rather than redesigns, and each is independently correctable in one pull request, so they are Bug children rather than a single oversized fix.
Neither correction preserves the current behaviour behind a switch. The depth inconsistency has no plausible caller depending on it, and _SourceFile is undocumented in the command's help — it appears only in the examples file. Whether provenance should be reintroduced as an opt-in is a design question for a follow-up, not part of the correction.
Both changes are user-visible in output content and warrant Minor rather than Patch.
Implementation plan
Delivery is tracked through the native sub-issues on this PBI.
Context and request
Two defects make
Jsonunsafe for its most obvious use case — reading a JSON file, changing a value, and writing it back. Both were reproduced locally againstmain.Export-Json -Depthis silently inconsistent: it defaults to2and is only honoured on the-Compactpath, because the pretty path delegates toFormat-Json, which hard-codes-Depth 100. The same command therefore truncates nested objects to strings like"@{l4=deep}"with-Compactand preserves them without it.Import-Jsonadds a_SourceFilenote property to every object it returns. Any import, modify, export round-trip writes that property into the output file.examples/General.ps1Example 18 demonstrates exactly this sequence and would produce a polluted file.Scope
In scope: depth handling across
Format-JsonandExport-Json, and the provenance property added byImport-Json.Out of scope: the pipeline-overwrite semantics of
Export-Json, which are documented and intentional, and any change toFormat-Json's indentation engine.Aggregate acceptance criteria
Export-Json -Depth <n>produces the same nesting depth with and without-Compact.Import-Jsonreturns carries a property that was not present in the source document.Technical decisions
Both are corrections rather than redesigns, and each is independently correctable in one pull request, so they are Bug children rather than a single oversized fix.
Neither correction preserves the current behaviour behind a switch. The depth inconsistency has no plausible caller depending on it, and
_SourceFileis undocumented in the command's help — it appears only in the examples file. Whether provenance should be reintroduced as an opt-in is a design question for a follow-up, not part of the correction.Both changes are user-visible in output content and warrant
Minorrather thanPatch.Implementation plan
Delivery is tracked through the native sub-issues on this PBI.