Stop writing CLI validation. Parse it right the first time

Original Article ↗ Hacker News Discussion ↗

Scope of parsing in everyday code

  • Some commenters say they rarely write parsers beyond Advent of Code or using JSON/YAML libraries.
  • Others argue parsing underlies most work: user input, CLI args, API payloads, server responses, and that many security bugs stem from not parsing properly at all.

“Parse, don’t validate” explained and debated

  • Supporters describe it as: turn loose data into a stricter type once, then use that type everywhere; don’t validate a loose type and keep passing it around.
  • Emphasis on reflecting invariants in the type system (“illegal states unrepresentable”), reducing scattered defensive checks.
  • Critics say it’s vacuous because “someone is still validating” (often a library like Zod/Pydantic); they see it more as an injunction to reuse good libraries.
  • Clarifications distinguish a parser (returns a new, constrained type) from a validator (predicate on existing value), and note structural vs nominal typing issues in TypeScript.

CLI parsing, Optique, and parser combinators

  • The featured TS library is seen as a specialized parser combinator toolkit for CLI, with strong type inference from parser declarations.
  • Comparisons are made to argparse, clap, docopt, Typer, PowerShell’s parameter system, and various TS/JS libraries; some say it’s closer to schema validation tools like Pydantic or Zod than to basic flag parsers.
  • Several note that parser combinators are conceptually simple and a good fit for argv streams.

Error reporting and invalid states

  • Concern: if you fully encode invariants, can you still report multiple errors or must you fail fast?
  • Responses: use applicative-style validation that accumulates errors into arrays/aggregates; have intermediate representations that allow invalid states but don’t leak them past the parsing boundary.

Design of CLI interfaces

  • Some argue complex dependent options indicate poor UX; prefer simpler schemes (positional args, enums like -t TYPE, combined host:port, DSNs).
  • Others accept required/related options as normal and value explicit named options over ambiguous positional arguments.

Type systems, layers, and safety

  • Disagreement over how much validation belongs in the I/O layer vs domain core.
  • General consensus that parsing to rich types at boundaries aids structure, but it doesn’t replace concerns like SQL injection; type safety is helpful but not absolute.

Languages, runtimes, and tooling

  • Debate over whether CLIs should be native binaries only vs being fine in Node/Python, especially internally.
  • Side discussion about static vs dynamic linking, libc compatibility, and appreciation for ecosystems with strong, type-aware CLI tooling (Rust’s clap, PowerShell, etc.).

Meta reactions

  • Some suspected the article was LLM- or machine-translated based on style; others found it novel, clear, and enjoyable, praising the concrete application of “Parse, don’t validate” to CLI design.