My use case is using dprint in a git precommit hook. When doing so, dprint fmt formats relevant files but returns a zero exit code. This causes the commit to go through, before having a chance to commit the formatted files.
Would it be possible to add some configuration option to return a non-zero exit code when dprint fmt formats files, and retain the current zero exit code when there are no errors otherwise?
$ cat >test.ts <<'# EOF'
let x = 0
# EOF
$ git add test.ts
$ git commit -m "add test.ts"
# using lefthook to manage precommit hooks, but would happen with other tools too
╭────────────────────────────────────────╮
│ 🥊 lefthook v1.11.13 hook: pre-commit │
╰────────────────────────────────────────╯
sync hooks: ✔️ (pre-commit)
┃ pnpm dprint fmt ❯
Formatted 1 file.
────────────────────────────────────
✔️ pnpm dprint fmt
[main edf04d5] add test.ts
1 file changed, 1 insertion(+)
create mode 100644 test.ts
$ git status
On branch main
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: test.ts
I didn't see this particular issue discussed in #442.
For reference, dprint behavior compared to similar tools:
dprint:
$ cat >test.ts <<'# EOF'
let x = 0
# EOF
$ npx dprint fmt --plugins https://plugins.dprint.dev/typescript-0.95.3.wasm -- test.ts
Formatted 1 file.
$ echo $?
0 # can I configure this to be non-zero?
prettier's pretty-quick, which is designed to be used in this scenario, can be configured to exit 1
$ cat >test.ts <<'# EOF'
let x = 0
# EOF
$ npx pretty-quick --pattern test.ts --bail
🔍 Finding changed files since git revision .
🎯 Found 1 changed file.
✍️ Fixing up test.ts.
✗ File had to be prettified and prettyQuick was set to bail mode.
$ echo $?
1
I was able to workaround this issue by capturing the exit code from dprint check:
pnpm dprint check --log-level silent; exit=$?; pnpm dprint fmt; exit $exit
but this is not ideal.
My use case is using dprint in a git precommit hook. When doing so,
dprint fmtformats relevant files but returns a zero exit code. This causes the commit to go through, before having a chance to commit the formatted files.Would it be possible to add some configuration option to return a non-zero exit code when
dprint fmtformats files, and retain the current zero exit code when there are no errors otherwise?I didn't see this particular issue discussed in #442.
For reference, dprint behavior compared to similar tools:
dprint:
prettier's pretty-quick, which is designed to be used in this scenario, can be configured to exit 1
I was able to workaround this issue by capturing the exit code from
dprint check:but this is not ideal.