Skip to content

notes: validate version-output input instead of casting it #620

Description

@goosewobbler

Gap

@releasekit/notes casts its parsed input to VersionOutput and reads fields off it. versionOutputToChangelogInput guards only the top-level changelogs array — anything malformed below that surfaces as a raw TypeError rather than an actionable input error.

On main, today:

parseVersionOutput('{"changelogs":[{"packageName":"a"}]}')
→ TypeError: Cannot read properties of undefined (reading 'map')

The CLI reports that as a general error, so a user piping a hand-assembled or truncated file gets a stack-shaped message pointing at our internals instead of "this input is missing entries".

@releasekit/publish already does this properly — parseInput validates against a Zod VersionOutputSchema and raises INPUT_VALIDATION_ERROR with the offending paths. notes should match.

Scope

  • A Zod schema for the VersionOutput shape notes actually consumes, applied in parseVersionOutput after the envelope unwrap.
  • Failures raise InputParseError (or a new InputValidationError, mirroring publish's split) with the field paths.
  • Reuse or share publish's schema rather than writing a second one that can drift — they describe the same contract.

Context

Raised by Greptile on #616, which made notes accept the enveloped form of the same input. Confirmed pre-existing: bare input on main behaves identically, so it isn't a regression from that PR and was left out of it rather than expanding its scope.

Worth doing alongside — or as part of — the pipe-contract work in #544, since it hardens the same boundary.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions