Fixing git hooks and automating commit messages

Devin Rhode — Wed, 19 Feb 2025 21:23:43 +0000

I believe that git hooks represent a very nice middle ground.

To be clear, they will always fail in the case that you want to push some code, close your laptop, and let a ci/cd pipeline handle validations.

But in the case that you are not closing your laptop, I believe git hooks can be superior, if setup properly.

An important note:
Theo (t3dotgg) has made a few videos explaining why he hates git hooks so much. I have made some meager attempts to assuade him otherwise, but not sure that has gotten anywhere.

The biggest issue with git hooks, is the fact that they typically impede a workflow which did not have git hooks setup.

Quality checks usually take more than 30 seconds, typically 60 seconds, at which point, you start losing your flow state (IMO), and may be tempted to multi-task, which is definitely bad if they fail.
Even if the checks were fast, you may not even be expecting them to succeed! So any failure can wreck havoc on your workflow! Now your co-workers can't collaborate or help with your not-yet-perfect code, because your push or commit failed :).

======

A critical side quest: TypeScript strictness settings.
Please bare with me, "have faith!" as they like to shout from mountain tops.

Let's say I want to made the tsconfig.json type-checking settings more strict, or add some eslint rules, etc.

I personally like a very strict eslint config. It forces me to think harder about my code, and most importantly, is a vector for learning.

Perhaps developers would be more amenable to stricter type-checking settings, if it weren't such a BLOCKING issue.

Here I tie together this side quest: Let's not make quality checks such a blocker.

======

What if we had a simple command to add // @ts-expect-error - TS ERROR MESSAGE comments throughout our code? In some ways it's just a different output mechanism for tsc. If we could just add code comments with the error messages, yes it's ugly, but anyone in gitlab/github/etc can just view the error messages, and act accordingly. We can agree it's not a big issue, or not.

======

How should git hooks work, then?

They need to integrate with your dev server, wherever you are getting a read-out of typescript or other lint errors. A git/hook process needs to be able to make an IPC/request to a unix socket which the dev server exposes, and the dev server responds with... the current set of errors. I think by default we want a this dev server to add ts/eslint ignore comments into your code, but a parameter could be passed in to disable this behavior, and the errors are then shown in the terminal, and the error messages are put into the commit message.

This way, we let a git commit immediately succeed, but still make it clear what errors we have, whether in the code itself as a comment, or in the commit message.

======

Part 2: Git commit messages.

Something I have somewhat dreamed of, is a tool which can automatically git commit as I am developing. We could imagine that it should not auto-commit if there are type errors, but if there were type errors, and those are all now fixed, it seems like a reasonable time to auto-commit. The problem then, is, what should the commit message BE?

What to put in a 50-character commit message is a topic of great debate. Was it a mistake for git to require them in the first place? Certainly not at the time that git was created.

I believe it would be best to tie a commit message to a commenting system. We can then add commit messages later, when reviewing code, and can directly "reply" to a commit message, should an author want to embed an initial comment (i.e. a traditional-ish commit message). For such a commenting system to be robust when a developer utilizes rebasing, it's best for a developer to "title" the change, with something like ReactDOMRender or LangChangeSupportSpanish, etc. The idea here is to give it a unique-ish title, whereby comment systems can reliably create a single comment thread for the ReactDOMRender commit, even when there are multiple ReactDOMRender commit shas that have been created, due to rebasing.

We could also create these unique ID's automatically. We could first look at newly created (not changed) code, and select the top-most export/variable/function name. If there's a new file name, we could take the files name as the commit message, etc.

If some type error is taking some time to solve, this auto-commiting tool could just commit the state that you are currently at.

Great node version management

Devin Rhode — Thu, 18 Nov 2021 22:29:18 +0000

Here's a package.json:

{
  "...": "...",
  "engines-comment": [
    "When new node/yarn versions are released, you may see these errors:",
    "  engine \"yarn|node\" is incompatible with this module.",
    "Just bump version numbers below:"
  ],
  "engines": {
    "node": "16.13.x",
    "yarn": "1.22.15"
  },
  "node-version-rationale": [
    "Give some flexibility by ignoring patch updates",
    "but otherwise force developers to update node every couple 1-4 months"
  ],
  "yarn-version-rationale": [
    "Exact yarn version helps us produce consistent yarn.lock files"
  ]
}

Our pipeline is set always try and use the latest lts.

Our pipeline will run:

# Always run install+build:ci with latest LTS, to see output
# But verify engines at very end
yarn config set ignore-engines true

yarn install --frozen-lockfile

yarn build:ci

yarn config set ignore-engines false
yarn verify-node-and-yarn-versions-against-package-json-engines

So, we always use latest node LTS in our pipelines. BUT, we don't let a major version bump just fly by - as safe as node releases are - we will require explicit acknowledgement from a developer to use new major version of node LTS.

Now, why use node 16.13.x?
If you want to be strict - by all means set an exact version number. Based on node LTS release history, I estimate you'll need to update package.json engines version every 1-4 weeks.

But if you specify only an exact minor version, you'll only need to update package.json engines version about every 1-4 months.

v14 LTS was cut 10/27/2020
minor version bumps happened on: 9/28, 5/11, 2/23, 10/27
4 months, 3 months, 4 months

v12 LTS was more turbulent (probably due to es modules): 3/30, 2/23, 11/24, 10/6, 6/2, 5/26, 2/11, 2/5, 12/17
1 month, 3 months, 2 months, 4 months, 1 week, 3 months, 1 week, 2 months

v10 LTS: 2/23, 10/27, 7/21, 3/26, 2/5, 12/17, 10/22, 5/28, 12/26, 11/27, (10/30-first v10 lts)
4 months, 3 months, 4 months, 2 months, 2 months, 2 months, 5 months, 7 months, 1 month, 1 month

On mac and linux, if you use NVM, you should setup a bash or zsh profile script to automatically set node version when you cd into a project with a .nvmrc file.

We set out .nvmrc file to: lts/* which means "latest lts" - this is the same as our ci/cd pipeline.

This means, every time you cd into a project, nvm will use the latest lts. (I am assuming nvm does a network call at some point to see what lts/* should map to)

However, if some developers have not setup this zsh/bash script, or are using windows, or maybe they just simply don't want to automatically update node – Then the package.json engines check will force them to at least update every 1-4 months.

Updating the node minor version every 1-4 months feels like a great cadence to maybe update dependencies in your package.json.

Tangent: I need to do some digging on https://Volta.sh, it may be the only option for some developers using windows.

DEV Community: Devin Rhode

Fixing git hooks and automating commit messages

Great node version management