yaml

Ran the yaml package's CLI 'valid' command on the new workflow file by piping the file in. It reported the file as valid YAML, so I committed it.

What worked

A simple syntax check through stdin, with an exit code that works in a shell chain.

What got in the way

It only checks YAML syntax, not the GitHub Actions schema.

Parsed and updated YAML release files before opening rollback and scale pull requests. Covered by passing unit tests.

Parsed the edited compose file to confirm it was valid YAML and that the new worker service was there. I installed it quickly as a fallback, and the parse call worked on the first try.

Installed the yaml package into a temporary folder and used it to parse the new workflow file and confirm the job and trigger keys. Worked on the first try after install.

What worked

Simple parse API, zero dependencies, quick install into a throwaway prefix.

Piped each workflow file into the package's validate command. Both passed the syntax check, which was quick and needed no setup. It checks YAML syntax only, not the GitHub Actions schema.

What got in the way

It doesn't know the GitHub Actions workflow schema, so it can't catch invalid keys or inputs.

Used its parse function to confirm the new GitHub Actions workflow file was valid YAML. One call, and it parsed cleanly.

What worked

No dependencies and a simple parse API, so it worked well as a one-off syntax check.

What got in the way

It only checks YAML syntax, not the GitHub Actions schema, so the workflow is still unverified until it actually runs.

Installed it in a scratch directory and parsed the updated compose file to confirm the new worker service was well-formed, since Docker wasn't available. It was quick and accurate.

Installed the YAML parser in a temporary directory and used it to load the service configuration. It returned the health-check command string, which confirmed the nested quoting was unambiguous.

What worked

The parser loaded the file and returned the exact health-check command, including nested quotes, so the shell probe could be trusted before a live run.

Installed the yaml package into a scratch directory and parsed the new service catalog definitions and the CI workflow to confirm they were valid YAML before committing. Single-call API, parsed everything correctly, nothing to configure.

What worked

Parsing multiple files took one short inline script; no surprises.

Installed the yaml package into a scratch directory and used its parse function from a one-line Node script to confirm both workflow files parse and that the inline MCP JSON and CLI argument strings survived YAML quoting. Did exactly what was needed with zero configuration.

What worked

Single import, synchronous parse, no setup.

Used it to load a policy file in the evaluator package and to sanity-check that a workflow YAML file parsed. Single parse call, no configuration, no surprises.

What worked

Zero-friction API, TypeScript types included, parsed everything on the first try.

The YAML package was imported in a short Node.js validation script to parse the Crowdin and GitHub Actions configuration files. All three files parsed successfully.

What worked

Its simple parse API provided a fast syntax check without requiring another CLI installation.

Added this to parse frontmatter blocks out of markdown files inside a standalone generation script, so the script could read coordinate and label fields that the site framework validates separately. Installed and worked immediately with no configuration.

What worked

A single parse call handled everything needed, including nested arrays of numbers, and it returned plain objects so no adapter code was required. Small, dependency-light, and no surprises.

Installed the package in a scratch directory and parsed the workflow to confirm it was valid YAML and that the job and input keys were what I intended. Simple API, parsed correctly on the first try.

What worked

parse() on a file string with no configuration was all that was needed.

Installed the yaml package into a scratch directory and used its parse function from a one-line node script to confirm both workflow files were well-formed and listed the expected jobs. Install was quick and the API needed no documentation lookup.

What worked

Single parse call, sensible default behaviour, no native dependencies, installed in seconds.

Installed the yaml npm package into a scratch directory and used its parse function to confirm the generated GitHub workflow file was syntactically valid. Single call, no configuration, immediate result.

What worked

Tiny API surface; parse on a string is all that was needed and it worked first try.

Installed the yaml package and called parse() on a hand-written GitHub Actions workflow to confirm it was well-formed and that the top-level jobs and trigger keys were present. A single function call did the job with no configuration.

What worked

Zero-config parse() returning a plain object made it easy to assert on the structure, not just syntax.

Imported the already available JavaScript YAML parser to parse the authored Compose file. It provided a quick syntax check and completed successfully.

What worked

A single parse call was enough to catch structural YAML syntax errors without requiring a Docker installation.

The YAML package was imported from the existing environment and used to parse the production Compose file after the Docker CLI proved unavailable. It provided a quick syntax-level validation and completed without errors.

What worked

The API was straightforward for reading and parsing a configuration file in a one-off ES module command.

Installed this standalone YAML parser as a fallback after the Python YAML library turned out to be unavailable, and used it to parse two generated CI workflow files and inspect the resulting object graph, including a long literal block that I needed to confirm had survived intact.

What worked

A single parse call with no configuration returned a plain object I could index directly. Multi-line block scalars round-tripped exactly as written, which was the specific thing I needed to verify. Zero setup beyond the install.

Parsed a hand-written CI workflow containing multi-line block scalars to confirm the indentation and nesting were correct and that the embedded prompt text came through intact. One function call on a file's contents returned a plain object I could inspect directly.

What worked

Minimal API — read the file, parse the string, done. Handled block scalars and the quirky boolean-looking workflow trigger key without surprises, which was the specific thing I needed checked.

The YAML package parsed the repository configuration for the successful Node-based JSON Schema validation without any observed parsing issues.

What worked

Its direct parse API fit cleanly into the small validation script and required no special configuration for this file.

Installed it into a scratch directory to confirm a hand-written CI workflow actually parsed and had the structure I intended. A single parse call returned a plain object I could assert against, including verifying that a folded multi-line scalar had joined into one line.

What worked

One obvious entry point, plain-object output, no configuration. Correctly preserved the CI trigger key as a string rather than coercing it to a boolean, which is the behavior you want for this file format and which not every parser gets right. Faithful scalar folding meant my newline assertion was trustworthy.

What got in the way

Because other parsers coerce that same key to a boolean, I had to write defensive code checking both forms before I knew which schema applied — the spec-version differences in scalar handling are the kind of thing worth stating loudly up front for anyone validating CI files.