You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: unify JSON output format between --json flag and HTML report's report.json #237
The HTML report writes a report.json alongside index.html using the internal ReportData shape, while --json outputs a different structure derived directly from findings. These two formats should be identical so tooling built on one works with the other.
I'd like to take this, but since changing --json is a breaking change for anyone parsing it, I want to agree on the target shape with you first.
Here is where the two differ today:
Top-level keys. --json (write-outputs.ts) emits mode, source, findingCount; report.json (the ReportData shape) emits scannedAt, cliVersion, packageManager, lockfileSource. They already share projectPath, packageCount, suggestedFixCommands, notes, warnings, skippedDependencies, and findings.
Findings. --json serializes each finding with serializeFinding; report.json uses serializeHtmlFinding, which is the same object plus riskSummary and nextAction.
Overrides. --json spreads overrideFindingsToJson(...) at the top level; report.json carries an overrideFindings array. Different shapes.
Multi-folder --json has its own separate { multiFolder, folders, findings } shape, which would need to fold in too.
My suggestion: make ReportData the single canonical schema and have --json emit it (both produced by one builder/serializer path), folding the useful --json-only fields (mode, source) into ReportData so nothing is lost, and settling on one overrides representation (the overrideFindings array). I would also add a schemaVersion field so downstream tooling can detect the change.
Two questions before I code:
Which way do you want to converge, --json onto report.json (my suggestion), or the reverse?
Are you OK with this being a breaking change to --json now, or would you prefer a deprecation window?
Happy to open the PR once you have picked a direction.
Activity
ELHart05 commentedon Jul 18, 2026
I'd like to take this, but since changing
--jsonis a breaking change for anyone parsing it, I want to agree on the target shape with you first.Here is where the two differ today:
--json(write-outputs.ts) emitsmode,source,findingCount;report.json(theReportDatashape) emitsscannedAt,cliVersion,packageManager,lockfileSource. They already shareprojectPath,packageCount,suggestedFixCommands,notes,warnings,skippedDependencies, andfindings.--jsonserializes each finding withserializeFinding;report.jsonusesserializeHtmlFinding, which is the same object plusriskSummaryandnextAction.--jsonspreadsoverrideFindingsToJson(...)at the top level;report.jsoncarries anoverrideFindingsarray. Different shapes.--jsonhas its own separate{ multiFolder, folders, findings }shape, which would need to fold in too.My suggestion: make
ReportDatathe single canonical schema and have--jsonemit it (both produced by one builder/serializer path), folding the useful--json-only fields (mode,source) intoReportDataso nothing is lost, and settling on one overrides representation (theoverrideFindingsarray). I would also add aschemaVersionfield so downstream tooling can detect the change.Two questions before I code:
--jsonontoreport.json(my suggestion), or the reverse?--jsonnow, or would you prefer a deprecation window?Happy to open the PR once you have picked a direction.
alex-powell commentedon Sep 20, 2026
Working on this.
fix(output): align HTML report.json with --json output shape
fix(output): align HTML report.json with --json output shape
fix(output): align the HTML report.json with the --json output shape (O…