Prettier using pre-commit(.com) does not re-stage changes
Asked Answered
M

3

7

I started using Prettier + eslint using pretty-quick & husky (option 2). It behaves as-expected, i.e., reformats code during a commit (or amend) and includes the changes in the commit.

My monorepo needed (several) more pre-commit hooks, so I ended up migrating to pre-commit.com (option 3). Now, when I commit or amend, Prettier modifies the files and returns Failed status. This creates for a rather annoying workflow where I am forced to add the files and attempt to commit the changes again.

Is there some way to re-stage the changes as part of the commit?

Magel answered 11/10, 2020 at 22:49 Comment(0)
E
16

pre-commit intentionally never touches the staging area. silently changing what is being committed is dangerous. the tool always gives you an opportunity to validate what the hooks do before committing

you can read more about this in the issue tracker:

My recommendation if you want to fire from the hip is to run git add -u && !! immediately afterwards -- this will stage the changed files and rerun the command you just ran

if you want to venture into unsupported territory, you can run this as part of the command (as demonstrated in one of the issues) -- but this subtly breaks a lot of the guarantees that the tool has

  - id: yapf
    entry: bash -c 'yapf "$@"; git add -u' --

disclaimer: I am the author of pre-commit

Ergocalciferol answered 11/10, 2020 at 23:2 Comment(2)
Thanks for the fast response! I figured that it was something like this. Given the number of GitHub issues, I would suggest (for your own sake) that perhaps this could be added to the docs (which I did read, a couple of times ;)Magel
Just as someone who face the same issue as you explained anthony sottile when I did this trick github.com/kasir-barati/you-say/blob/… and I was commiting part of a file it was adding the whole file if the file was changed by prettier. BTW I think its better to readd them manually. Just my understanding at 17.03.2023Lunseth
E
5

I'm sure my older brother, the creator of Pre-commit will confirm this, but this is the intended behavior of pre-commit. It should fail because it is directly modifying your files. I use this exact setup using Prettier for myself actually, and while it is annoying, it's just one of those things you gotta change. I like making a git commit -m called 'format' or something and then a commit for the actual change.

edit: he sniped me before I could answer, his answer goes much more in depth

Emarginate answered 11/10, 2020 at 23:4 Comment(0)
V
0

Assuming you understand the reasons given above to don't do this blindy, I'd like to share a simple rule script I wrote for the wonderful fuck which automatically updates the staging area and retry the commit command.

So, the usage looks like this:

$ git commit -m "..."
[pre-commit modifies some files and abort the commit]
$ fuck
Vansickle answered 19/5, 2021 at 3:52 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.