Support for Environment Variables - v1.0.0-rc.1

Release v1.0.0-rc.1

Environment Variables

Adds ability to configure environment variables to be set when invoking hook commands.
Variables are configured via the hook args: using the following argument pattern:

--hook:env:NAME=VALUE

The hook script will detect this argument and set the variable NAME to the value VALUE before invoking the configured tool.

You can pass multiple --hook:env: arguments.

The arguments can appear anywhere in the args: list (before an arg-terminating -- of course).

error-on-output

Previously, my-cmd-* hooks accepted a --error-on-output argument to signal when any output generated by the command should be treated as an error.

In order to try to minimize issues when using such a plain option, the option was required to be a the very first element of the args: list, ie.

args: [ --error-on-output, gofmt, -l, -d ]

This release adds additional support for a less-plain option:

• --hook:error-on-output

This option, being less-likely to cause issues with existing tools, can exist anywhere in the args list (before an arg-terminating -- of course), ie.

args: [ gofmt, -l, -d, --hook:error-on-output]

NOTE: The plain --error-on-output at first element still works (currently), but is now deprecated and will be removed in a future version

Invoking hook commands

Now uses /usr/bin/env to invoke commands

• No-longer invokes the commands directly
• Makes it trivial to pass environment variables to commands
• Should not cause issues as /usr/bin/env was already vital for using this library

Breaking Change

For compatibility with file-based hooks, Repo-based hooks
no-longer ignore '--', or proceeding arguments, in the argument list.
However, to further match file-based logic, the first '--' will be consumed,
treating anything after it as OPTIONS to be passed to the hook command.

Likely v1.0.0 Final

This release will likely become the official v1.0.0 release, but I'll give it a few weeks just in case recent changes added any bugs.

Support for Repo-Level revive.toml Config File - v1.0.0-beta.5

Release v1.0.0-beta.5

Adds Built-in Support for Repo-Level revive.toml Config File

Modifies revive hooks:

• Auto-adds -config=revive.toml argument if file is present in repository root
• Triggers hooks when repo-level revive.toml is modified
• Updates README

NOTE: Although the file-based go-revive hook is configured to trigger when revive.toml is modified, it will essentially do nothing if there are no .go files staged. We might consider adding some logic to run against ALL .go files in the repo, but I'm really not sure thats a good idea, and I probably didn't need to add a trigger to the file-level hook at all.

Full Changelog: v1.0.0-beta.4...v1.0.0-beta.5

---

cc: @mgechev, @adambabik

Support for staticcheck - v1.0.0-beta.4

Release v1.0.0-beta.4

Adds support for staticcheck

---

go-staticcheck

A state of the art linter for the Go programming language. Using static analysis, it finds bugs and performance issues, offers simplifications, and enforces style rules.

Hook ID	Description
go-staticcheck-mod	Run 'cd $(mod_root $FILE); staticcheck [$ARGS] ./...' for each staged .go file
go-staticcheck-pkg	Run 'staticcheck [$ARGS] ./$(dirname $FILE)' for each staged .go file
go-staticcheck-repo-mod	Run 'cd $(mod_root); staticcheck [$ARGS] ./...' for each module in the repo
go-staticcheck-repo-pkg	Run 'staticcheck [$ARGS] ./...' in repo root folder

Install (via bingo)

bingo install honnef.co/go/tools/cmd/staticcheck

Help

• https://staticcheck.io/
• staticcheck -h

---

courtesy ping to @dominikh

Fix -repo hooks; Breaking changes to hook args; Alias/Name Usage - v1.0.0-beta.3

Release v1.0.0-beta.3

• Fix -repo hooks
• Breaking changes to hook args
• Flesh out alias/name section in README

Fix -repo hooks

There was a bug in the newly introduced go-fmt based -repo hooks that broke the ability to add extra arguments to the hooks (via your pre-commit config args value)

A useful case for this might be setting the -w flag to allow fixing files in-place.

This release fixes the bug and can now support that use case for the various repo-level format hooks.

Breaking changes to hook args

Historically, the hooks accepted - as an alias for --, ie. stop processing flags and treat all further arguments as files.

using - as such an indicator is not really standard in any way, and I just had it as a convenience in case the user mistyped -- in their hook config.

As we approach a 1.0.0 release, I realize that this behavior could have a limiting factor on future tools, so I've decided to fix it now.

The hooks have special logic to auto-identify flags vs files and in most cases, the user doesn't even need to use --, so there's a good chance that this change hasn't affected any users.

Aliases / Names

I fleshed out a section in the docs that discusses some of the benefits of using aliases and names in your hook configurations. Namely:

• Creating short names for long-named hooks for easier CLI usage
• Having variations of a given hook with different configurations

You can read more about it in the README

Support for go mod tidy, gofump; Breaking changes to my-cmd hooks - v1.0.0.beta.2

Release v1.0.0-beta.2

On the heels of the beta.1 release we already have a beta.2 update :

• Breaking changes to my-cmd hooks
• Support for go mod tidy
• Support for the gofumpt code formatter
• -repo versions of the go-fmt related tools

---

Breaking change to my-cmd hooks

One of the comments of my beta.1 release was from a user who was excited to be able to add go mod tidy as a custom my-cmd took.

Reading his comment made me realize that the my-cmd hooks actually couldn't support his use case, due to an assumed ./... argument in the module hooks.

I knew then that I needed to remove the auto-added ./... argument from those hooks, and get the fix out before too many people created their own my-cmd hooks that relied on it.

With this release (almost) all my-cmd hooks now have no default arguments are *completely configured via the hook args.

The only exception is the my-cmd-pkg hook, who's which passes the folder of modified files to the hook command. This requires computational logic to determine the parent folders of modified files, and so cannot be duplicated via the args.

---

go-mod-tidy

Makes sure go.mod matches the source code in the module.

Hook ID	Description
go-mod-tidy	Run 'cd $(mod_root $FILE); go mod tidy [$ARGS] ./...' for each staged .go file
go-mod-tidy-repo	Run 'cd $(mod_root); go mod tidy [$ARGS] ./...' for each module in the repo

Install

Comes with Golang ( golang.org )

Help

• https://golang.org/ref/mod#go-mod-tidy
• go mod help tidy

---

go-fumpt

Enforce a stricter format than gofmt, while being backwards compatible.

• Replaces go-fmt
• Can modify files (see -w)

Hook ID	Description
go-fumpt	Run 'gofumpt -l -d [$ARGS] $FILE' for each staged .go file
go-fumpt-repo	Run 'gofumpt -l -d [$ARGS] .' in repo root folder

Install (via bingo)

bingo install mvdan.cc/gofumpt

Useful Args

-d=false : Hide diffs
-extra   : Enable extra rules which should be vetted by a human
-s       : Try to simplify code
-w       : Update source file directly

---

-repo versions fo go-fmt related tools

Although I don't believe it was always the case, I just discovered that you can pass directories to go-fmt (and tools derived from it).

I've added -repo versions fo the existing tools (and the new gofumpt tool) to support checking your entire repo:

Hook ID	Description
go-fmt-repo	Run 'gofmt -l -d [$ARGS] .' in repo root folder
go-fumpt-repo	Run 'gofumpt -l -d [$ARGS] .' in repo root folder
go-imports-repo	Run 'goimports -l -d [$ARGS] .' in repo root folder
go-returns-repo	Run 'goreturns -l -d [$ARGS] .' in repo root folder

On The Road To 1.0 - v1.0.0.beta.1

Release v1.0.0-beta.1

I'm excited to announce that v1.0.0 is finally on the horizon !

This release accomplishes the two biggest things I wanted to reach v1.0.0:

• Invoking Custom Tools
• Removing Duplicate Code

Read below to learn more about both of these.

See the project's readme for more in-depth documentation.

NOTE: Due do the extent of new code in this release, I'm first releasing it as a beta until it has some time in the wild.

I've done a lot of local testing, but I don't have an automated test suite for the project yet, so please take a minute to report issues if you find any.

---

Invoking Custom Tools

While this project includes builtin hooks for many popular go tools, it's not possible to include builtin hooks for every tool that users might want to use.

To help accommodate those users, this release introduces the ability to invoke custom go tools.

Using the my-cmd-* hooks, you can invoke custom go tools in various contexts.

Hook ID	Description
my-cmd	Run '$ARGS[0] [$ARGS[1:]] $FILE' for each staged .go file
my-cmd-mod	Run 'cd $(mod_root $FILE); $ARGS[0] [$ARGS[1:]] ./...' for each staged .go file
my-cmd-pkg	Run '$ARGS[0] [$ARGS[1:]] ./$(dirname $FILE)' for each staged .go file
my-cmd-repo	Run '$ARGS[0] [$ARGS[1:]]' in the repo root folder
my-cmd-repo-mod	Run 'cd $(mod_root); $ARGS[0] [$ARGS[1:]] /...' for each module in the repo
my-cmd-repo-pkg	Run '$ARGS[0] [$ARGS[1:]] ./...' in repo root folder

Configuring the hooks

The my-cmd hooks are configured entirely through the pre-commit args attribute, including specifying which tool to run (ie $ARGS[0] above)

Examples

Here's an example of what it would look like to use the my-cmd hooks to invoke go test if it wasn't already included:

.pre-commit-config.yaml

# ...
      hooks:
            # Run 'cd $(mod_root $FILE); go test ./...' for each staged .go file
        -   id: my-cmd-mod
            name: go-test-mod
            alias: go-test-mod
            args: [ go, test ]

---

Removing Duplicate Code

This release constitutes a huge re-factoring of the code, moving common logic into the lib/ folder, and removing as much code duplication as possible.

For example, here is the complete content of go-lint.sh :

#!/usr/bin/env bash
# shellcheck disable=SC2034  # vars used by sourced script
error_on_output=0
cmd=(golint -set_exit_status)
# shellcheck source=lib/cmd-files.bash
. "$(dirname "${0}")/lib/cmd-files.bash"

Thats it !

This should make it much easier to add new hooks, as well as all hooks being able to take advantage of future bug fixes and enhancements to the common code.

Support for revive - v0.8.3

Release v0.8.3

Adds support for the revive style checker

---

go-revive

~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint.

Hook ID	Description
go-revive	Run 'revive [$ARGS] $FILE' for each staged .go file
go-revive-mod	Run 'cd $(mod_root $FILE); revive [$ARGS] ./...' for each staged .go file
go-revive-repo-mod	Run 'cd $(mod_root); revive [$ARGS] ./...' for each module in the repo

Install

go get -u github.com/mgechev/revive

Useful Args

-config [PATH]     : Path to config file (TOML)
-exclude [PATTERN] : Pattern for files/directories/packages to be excluded from linting
-formatter [NAME]  : formatter to be used for the output

Displaying Warnings

By default, revive doesn't generate errors on warnings, so warning messages may not be displayed if there are no accompanying error messages.

You can use the "verbose: true" hook configuration to always show hook output.

Help

• https://github.com/mgechev/revive#usage
• revive -h

Support for gosec - v0.8.2

Release v0.8.2

Adds support for the gosec security checker

---

go-sec

Inspects source code for security problems by scanning the Go AST.

Hook ID	Description
go-sec-mod	Run 'cd $(mod_root $FILE); gosec [$ARGS] ./...' for each staged .go file
go-sec-pkg	Run 'gosec [$ARGS] ./$(dirname $FILE)' for each staged .go file
go-sec-repo-mod	Run 'cd $(mod_root); gosec [$ARGS] ./...' for each module in the repo
go-sec-repo-pkg	Run 'gosec [$ARGS] ./...' in repo root folder

Install

go get github.com/securego/gosec/v2/cmd/gosec

Help

• https://github.com/securego/gosec#usage
• gosec (no args)

Exclude ALL Vendor Folders : v0.8.1

Release v0.8.1

Updates the pattern for ignoring vendor folders from ./vendor/* to */vendor/*, which should now also ignore vendor folders beneath the root folder.

'--' Now Optional In Hook Args : v0.8.0

Release v0.8.0

A trailing '--' is now (mostly) optional when passing options into hooks.

if your options contain a reference to an existing file, then you will need to use a trailing '--' argument to separate the hook options from the modified-file list that Pre-Commit passes into the hook.

Note: For repo-based hooks, '--' is not needed.