Skip to content

Add deterministic YAML stream formatting #5

Closed

Description

Why

YAML files and generated YAML streams can accumulate inconsistent indentation, comments, flow presentation, directives, and scalar styles. Automation needs a safe way to normalize presentation without losing YAML-only representation details that cannot be projected through PowerShell objects.

What

A public formatter that accepts complete YAML text or line-oriented pipeline input and returns one deterministic YAML stream. Formatting preserves document boundaries, empty documents, node kinds, scalar content, effective tags, anchors and aliases, recursive graphs, complex keys, collection structure, and mapping order.

Acceptance criteria

  • Format-Yaml accepts string[] pipeline input, joins records with LF, and returns exactly one string
  • Output uses explicit document starts, configurable indentation, LF line endings, and no final newline
  • Comments, directives, document-end markers, flow presentation, scalar styles, and source anchor names are normalized deterministically
  • Formatting is byte-idempotent at the same options
  • Parser safety controls and classified YAML failures match ConvertFrom-Yaml
  • The official 402-input YAML corpus verifies representation preservation, valid reparse, invalid rejection, and idempotence without changing existing corpus surfaces
  • Public help, generated documentation, examples, exports, source tests, artifact tests, analysis, and site builds include the formatter

Activity

  1. changed the title [-]🚀[Feature]: Function: Format-Yaml[/-] [+]Add deterministic YAML stream formatting[/+] on Jul 25, 2026
  2. MariusStorhaug commented on Jul 25, 2026

    @MariusStorhaug
    MemberAuthor

    Structured the work item into the canonical three-section format and recorded the completed delivery.

    • Added user-facing acceptance criteria for deterministic, representation-preserving formatting
    • Documented the direct representation-emission, normalization, safety, and conformance decisions
    • Marked the implementation, test, documentation, packaging, and cross-platform validation tasks complete
    • Linked the stacked draft pull request
  3. MariusStorhaug commented on Jul 26, 2026

    @MariusStorhaug
    MemberAuthor

    What changed: Reformatted the issue body to the MSXOrg Issue Format — a local Why plus an outcome-level What/acceptance criteria. Removed the Technical Decisions and Implementation Plan sections (and other implementation-tradeoff notes).
    Why: Issue bodies should state local purpose and observable outcome without leaking implementation detail into the outcome-level description; durable technical decisions belong in the PR/design, not the tracking issue.
    Follow-up: None.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions