fix(export): exit 0 on a successful export regardless of source lint findings - #126
Conversation
…findings The export command derived its exit code from the source's lint summary, so exporting a file that had any lint *error* exited 1 even though the export produced correct output. That conflates "the source has lint findings" (which `lint` already reports by exiting 1) with "the export failed." Decouple them: a successful export exits 0; only an invalid --format or an emitter failure exits 1 (and an unreadable input exits 2, via readInput). Document the export exit codes in the README.
rajpratham1
left a comment
rajpratham1
left a comment
There was a problem hiding this comment.
This is a sensible fix that clearly separates the responsibilities of the export and lint commands. If an export successfully produces output, it should exit with 0 regardless of lint findings, while lint remains the command responsible for enforcing validation failures. The added regression tests cover both behaviors, and the README has been updated to document the exit code semantics.
rajpratham1
left a comment
rajpratham1
left a comment
There was a problem hiding this comment.
This change corrects the CLI behavior by separating export success from lint validation. If an export is successfully generated, it should return a success exit code regardless of validation findings, while lint remains the command responsible for enforcing validation failures. The implementation is small, well-scoped, and backed by appropriate regression tests and documentation updates.
davideast
left a comment
davideast
left a comment
There was a problem hiding this comment.
Thank you yet again (and again) @rmyndharis!
The success branches (css-tailwind, json-tailwind, dtcg, css-vars) write their output but never assign process.exitCode, so a successful export left the code at its incoming value instead of an explicit 0. That is the success-path counterpart to #126, which decoupled the exit code from source lint findings; the subprocess test there only exercises json-tailwind and a real process happens to exit 0 when exitCode is unset, so the gap went unnoticed. Set process.exitCode = 0 after the format branches (every error branch already returns first). The in-process export.test.ts added in #109 asserts process.exitCode === 0 after a css-vars export, so it was failing on main. Also fix a companion assertion in that file: it read error.error for the human message, but the error envelope is { error: CODE, message: TEXT }, so the text lives on error.message. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
3 participants
Summary
exportset its exit code from the source's lint summary:So exporting a DESIGN.md that has a lint error (e.g. one invalid color) exited
1even though the export ran and produced correct output for every valid token. That conflates two different things — "the source has lint findings" and "the export failed" — in one exit code, and it's undocumented.Change (behavior change)
Decouple the export exit code from source lint findings:
lintto gate on those)--formator an emitter failurereadInput)Documented in the README's
exportsection. This is a deliberate behavior change on the success path (export of a lint-error file:1→0); flagging it explicitly in case the coupling was intended as a validation gate —lintalready serves that purpose.Testing
commands/export-exit-code.test.ts(spawns the CLI): export of a lint-error file → exit0with output;lintof the same file → exit1.bun test: 284 pass, 1 skip, 0 fail.bun run lint: clean.