Skip to content

Conversation

@martinemde
Copy link

@martinemde martinemde commented Dec 17, 2025

This change adds a json output option and provides a schema to describe the output format. The goal is to be able to programmatically parse the output of pks check for other tools like danger.

We decided to split the idea of a stale todo from the idea of a violation, since even though they talk about the same idea, the have different meanings.

  • A stale todo is a leftover reference to a problem that no longer exists. The fix requires no work other than running pks update. It's a lint warning.
  • A violation should be address via a choice by the developer to either repair the violation, change the package config, or add it to the todo.

Copy link

@ivy ivy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me outside of a design detail: I think we should exit with a non-zero status code when there are violations.

Also suggested a doc comment to point readers/agents to the JSON schema. Love that you added a test that validates against it! 💜

@@ -0,0 +1,104 @@
use itertools::chain;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
use itertools::chain;
//! JSON output formatter for `pks check -o json`.
//!
//! Serializes check results (violations, stale TODOs, and summary) to JSON.
//! See `schema/check-output.json` for the JSON Schema specification.
use itertools::chain;

.arg("-o")
.arg("json")
.assert()
.success()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.success()
.failure()

.arg("-o")
.arg("json")
.assert()
.success()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.success()
.failure()

csv::write_csv(&result, std::io::stdout())?;
}
OutputFormat::JSON => {
json::write_json(&result, std::io::stdout())?;
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should exit with a non-zero status when there are violations:

Suggested change
json::write_json(&result, std::io::stdout())?;
json::write_json(&result, std::io::stdout())?;
if result.has_violations() {
std::process::exit(1);
}

I wonder if we should use a different code versus a runtime error? This way, callers don't have to differentiate "runtime error as plain text" versus "violations presented as JSON".

Validate against the included schema for check json output

Co-authored-by: Ivy Evans <ivy.evans@gusto.com>
@martinemde martinemde force-pushed the martinemde/kkpvkpnwpymy branch from ef59b76 to 165a8da Compare December 17, 2025 21:48
This follows the convention used by linters like eslint, rubocop, and shellcheck.
Builds on clap's existing behavior.

All output formats (packwerk, json, csv) behave consistently:
- Exit 0 when no violations
- Exit 1 when violations found
- Exit 2 on internal errors
@martinemde martinemde force-pushed the martinemde/srkpxtkmqznx branch from 270ac28 to b722534 Compare December 18, 2025 01:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Triage

Development

Successfully merging this pull request may close these issues.

3 participants