feat: add pre-commit hook for gofumpt formatting

[Luigi31415]

Summary

This pull request introduces a pre-commit hook for formatting Go code using gofumpt. The hook automates the process of ensuring Go files adhere to gofumpt's strict formatting guidelines prior to committing, improving code consistency across the project.

Changes

• Added a .pre-commit-hooks.yaml file defining a new hook, gofumpt-format, that runs gofumpt on all Go files (.go).
• The hook uses a custom shell script (run-go-fumpt.sh) to execute the gofumpt command, ensuring proper error handling and capturing output for the user.
• This setup can be utilized by other projects that want to integrate gofumpt with pre-commit.

How to Use

1. Add the following to your .pre-commit-config.yaml in the target repository:

   repos:
     - repo: https://github.com/NaturalT314/gofumpt
       rev: <commit-hash-or-tag>
       hooks:
         - id: gofumpt-format

2. Install pre-commit hooks by running:

   pre-commit install

This ensures that Go files are automatically formatted when a developer attempts to commit changes.

Motivation

Automating code formatting ensures all contributions meet consistent style guidelines. Using pre-commit hooks allows teams to catch formatting issues before they are introduced into the codebase, reducing unnecessary review overhead and merge conflicts.

Testing

Tested the pre-commit hook on local Go projects and confirmed that it formats files correctly and outputs relevant changes before commits.

Related Issues

None at this time.

Please let me know if any further changes or additions are required. Thank you for considering this contribution!

[ccoVeille]

Your solution works, but it could be way better I think

[ccoVeille]

I would suggest using something like this

https://github.com/shutter-network/pre-commit-go-hooks/blob/main/.pre-commit-hooks.yaml

By using language and addition dependency

[mvdan]

Thank you for the patch but I would rather not add this. See mvdan/sh#554 for my reasoning why. Running gofumpt is already easy, so a shell script and YAML file are unnecessary. If pre-commit requires these to mark the project as "supported" that is something they should improve on their end. We have tried making suggestions like that and the thread got locked.

If someone prefers to maintain their own pre-commit repo I won't oppose that of course.

[ccoVeille]

And also it already exists (as mentioned here)

https://github.com/shutter-network/pre-commit-go-hooks (hi @schmir 👋)

[jeeftor]

I would argue you should actually consider supporting it in the repo.

1. You only need to add a hook file
2. Pre-commit natively supports installing go packages as-is

So really all you have to do is add this single file and then you support pre-commit hooks.

Also regarding the PR I think you can get away with something as simple as:

.pre-commit-hooks.yaml

---
    - id: format
      name: gofumpt 
      description: Checks license headers in staged files
      entry: gofumpt -w 
      language: golang
      types: [file] 
      pass_filenames: true 
      require_serial: true
      stages: [pre-commit]
      minimum_pre_commit_version: 3.0.0

I'm about 90% sure thats it and to use a hook you'd go with:

repos:
  - repo: https://github.com/mvdan/gofumpt
    rev: v0.7.0
    hooks:
      - id: format
        verbose: true   
        types_or: [go]
        exclude: ^vendor/|/vendor/

I just wrote a set of pre-commit hooks for a new tool I put together today. And then I was looking at the other tools in my setup and thought it would be nice if they had pre-commit hooks too.

[jeeftor]

For golines its just super basic - to add useful functionality

[schmir]

I've read the linked issues now for a second time.

@mvdan I think you should just add those single yaml file to the repo in order to serve your users instead of arguing for a change in pre-commit. You spent so much time developing your software and yet refuse to make that little change. You make it harder for your users to use it, because you think there should be a better solution implemented in pre-commit. That might be right, but doesn't serve your users.

[jeeftor]

Also:

Thank you for the patch but I would rather not add this. See mvdan/sh#554 for my reasoning why. Running gofumpt is already easy, so a shell script and YAML file are unnecessary. If pre-commit requires these to mark the project as "supported" that is something they should improve on their end. We have tried making suggestions like that and the thread got locked.

I don't think pre-commit requires projects to be supported. When it was first launched they listed TONS of hooks on their webpage -> now they only list "featured" projects. So you can easily have hooks w/out being in their featured list. - I did read through the history and I guess you are frustrated with this: pre-commit/pre-commit#1460 - the verbosity of the file?

Or do you mean you want to be listed on the supported page?

The reason I'm writing this is I used to run all my hooks with a local repo -> until I launched a go-utility for managing licenses and realized its SUPER easy to get go-hooks to auto-install ... started looking around and realized ya'll dont have one.

@mvdan -> I'm happy to open a new (simpler) PR for you if you'd like and write up docs if you are willing to consider it. or we can continue discussion here ... but I don't want to waste my time if you are dead set on NO

:)

[mvdan]

I'm sorry but I continue to be opposed to adding "official support" for pre-commit as I've outlined before. Installing this tool is exactly the same as any other standard Go project. There is no special parameters that I need to declare here in a YAML file for external tools to know how to build or run it.

I tried to engage with pre-commit in good faith over on pre-commit/pre-commit#1460 to suggest improvements so that declaring a local hook would be just a few straightforward lines. They rejected the idea and locked the thread, which is unfortunate. I honestly do not want to spend more time engaging with that project after the exchange.

pre-commit users can either use local hooks (even if verbose), or third party repos declaring these hooks. I don't see anything wrong with that.

[ccoVeille]

I agree with @mvdan

also @jeeftor You can also take a look at @dnephin post here about why he was stopping to support pre-commit-golang project he maintained for a while.

• dnephin/pre-commit-golang 🚨 Project sunsetting 🌆  dnephin/pre-commit-golang#98 (comment)

As you can see the other existing projects about pre-commit are in stale mode

• https://github.com/Bahjat/pre-commit-golang
• https://github.com/TekWizely/pre-commit-golang

I think it's for the same reason as @mvdan state, anyone can do it by its own once they understand how to use the local hooks inside pre-commit configuration.

That said, I saw a comment of @bhundven here dnephin/pre-commit-golang#98 (comment) where he says he wants to bring back pre-commit-golang hooks to life on a repository he plans to maintain: https://github.com/bhundven/golang-pre-commit

He is open to contribution, so anyone could consider to open PR on his repository.

[jeeftor]

I won't push this further - my only frustration is I have to end up writing a local hook and having the CI make sure the go packages are downloaded - juts seems like a waste of time :)

[ccoVeille]

For record @bhundven added support of gofumpt in his repository

• feat: Add gofumpt bhundven/golang-pre-commit#20