[rush] Support Husky for git commit hooks

[jbcpollak]

I'd like to be able to use commitlint in my project. Traditionally we've used husky to setup git commit hooks and commitlint goes from there.

One option I've considered (but I haven't tried yet) is to create a commit-hooks project with a simple package.json that does what we need. The issue here would be if husky is able to traverse up the tree to find our .git and register the hooks correctly. Otherwise this should work.

Alternatively first class rust support would be ideal.

@pgonzal wrote:

I feel like this would ideally make sense as a first class Rush feature, since Rush would want your scripts to go somewhere like common/scripts/commit-hooks and Rush is usually invoked very early in the workflow and could easily configure the Git hooks.

We would probably also prefer for the hooks to be separated into a nice common/config/git-hooks.json or whatever with a validated schema.

However as a short term workaround, it would be totally fine to put a package.json in your repo root, as long as it doesn't have any dependencies or devDependencies in it that get installed

[octogonz]

The issue here would be if husky is able to traverse up the tree to find our .git and register the hooks correctly.

I was thinking about this a bit more. If Husky's package.json has a postinstall script that is trying to discover "which package installed Husky", there are a couple problems with that:

1. In a Rush repo, effectively Husky is an indirect dependency of the common/temp/package.json file. The direct dependency isn't your commit-hooks project, but rather the @rush-temp/commit-hooks synthetic project which won't have any of the other package.json fields.
2. If the repo is using PNPM, then looking upwards in the directory tree isn't going to reveal "the" package that installed husky, because in a directed-acyclic-graph there can be multiple parent folders. (This is how PNPM avoids duplicated installs.)

We could try to work around this, but these two strategies both feel flawed in a modern package manager environment: (1) trying to configure the entire repo during a postinstall hook for a single package, and (2) trying to discover the package that caused Husky to be installed. Once the Git hooks are boostrapped though, the rest of the Husky model seems fine (i.e. using a package.json file somewhere to describe the hooks that you want to invoke).

Having never used Husky myself, I'm making a lot of assumptions here which might be incorrect. But if I understand right, the solution might look something like this:

• Somehow prevent Husky from trying to configure Git during its postinstall hook
• Instead configure Rush to invoke Husky explicitly, e.g. I believe Rush has a global postRushInstall hook that could be configured to run Husky's setup script
• As part of this, tell Husky the location of your commit-hooks project; it can then parse the package.json as usual whenever Git sends an event to Husky

[natalieethell]

@pgonzal and I recently implemented a workaround for this Husky issue in this PR to upgrade Office UI Fabric React to use Rush 5.

We created a new script, install-husky.js, and used husky/src/install as the entry point:

let path = require('path');
let husky = require('husky/src/install');
// "src" is needed because husky normally expects to look upwards from
// its "src" folder
husky(path.resolve(__dirname, 'src'));

In the rush.json, we inserted a new eventHooks field to run this script after rush install:

"eventHooks": {
    "postRushInstall": [
      "node scripts/install-husky.js"
    ]
  },

[octogonz]

I'm going to close this issue. Natalie provided a pretty reasonable workaround, and #821 seems like an easier long term solution.