husky: Husky setting wrong folder in monorepo (lerna/yarn workspace)

@tad3j , @bertdeblock thank you guys, now I see, I have reproduced the issue.

Steps to reproduce

1. Create a monorepo using lerna with yarn workspaces enabled.
2. Add husky as dependency in the root package.
3. Configure a pre-commit hook in the root package.
4. Change directory to one of the packages in the monorepo.
5. Remove any valid dependency of that package by running yarn remove <any dependency>.
6. Stage and commit any changes.

Expected result The specified pre-commit hook is executed by husky prior to commit. Actual result The hook is not executed.

Presumably, the same behaviour can be observed with other commands that trigger package reinstallation, like yarn install <...>.

I will take a closer look at this issue later today.

Update: For the record, .git/hooks/husky.local.sh is updated as follows. Before:

# Created by Husky v4.2.3 (https://github.com/typicode/husky#readme)
#   At: 3/23/2020, 6:59:15 AM
#   From: /workspaces/instrumentation/node_modules/husky (https://github.com/typicode/husky#readme)

packageManager=yarn
cd "."

After:

# Created by Husky v4.2.3 (https://github.com/typicode/husky#readme)
#   At: 3/23/2020, 10:38:18 AM
#   From: /workspaces/instrumentation/node_modules/husky (https://github.com/typicode/husky#readme)

packageManager=yarn
cd "packages/test_package/"

+1, git hooks have been a terrible problem in yarn workspaces.

+1 for this issue’s priority, a team I’m on is running into this issue often as well. The workaround of only running yarn commands in a monorepo’s root is hard to engrain in devs’ workflow and things that get past some githooks take some extra coordination to fix again. For the time being, we’ll be using the patch in #728

How about a flag to prevents husky from overriding the cd "." in git/hooks/husky.local.sh? something like:

if(HUSKY_RUN_FROM_PROJECT_ROOT) {
  cd = "."
} else {
  cd = ... // do whatever you do now
}

I thought I would add my two cents as I had a junior dev bypass the postinstall script suggestion @nickgieschen suggested using --ignore-scripts

I created a huskypostinstall.ts at the top level of the monorepo containing:

import fs from 'fs';

const huskyHookLoc = '../../.git/hooks/husky.local.sh';

if (fs.existsSync(huskyHookLoc)) {
  fs.readFile(huskyHookLoc, 'utf-8', (err, data) => {
    if (err) throw err;
    const newData = data.replace(/cd.*$/gim, 'cd "."');

    fs.writeFile(huskyHookLoc, newData, 'utf-8', (err) => {
      if (err) throw err;
      // eslint-disable-next-line no-console
      console.log('husky post-install fix applied');
    });
  });
}

process.exit(0);

and then added it as the “postinstall” script in each repo: "postinstall": "cross-env TS_NODE_COMPILER_OPTIONS={\\\"module\\\":\\\"commonjs\\\"} ts-node ../../huskypostinstall.ts"

Your mileage may vary with the above (we’re using TS & modules etc.) but the general principles are:

1. use fs to read from the hooks script file
2. use /cd.*$/gim to replace the cd line with cd "."
3. write back to file

The issue is not about removing Husky itself, but about removing another dependency from inside a package directory.

I’m also using the same setup (Yarn Workspaces + Lerna) and I’ve noticed the exact same issue.

@naorzr, although we have a pretty good understanding of why this is happening, fixing this behavior is not trivial. As far as I can tell, this behavior is due to the way the hooks were designed in husky in the first place. Fixing the issue requires a substantial change in the way hooks are managed by husky and the risks are high that fixing this issue might break other use cases. Making the situation worse, if hooks stop working, it might not be immediately apparent to the users because hooks tend to fail without notice. Given the wide adoption of husky and the limited attention that this issue has received, I believe that fixing this issue at the risk of breaking mainstream scenarios is not worthwhile.

To support this fix and make sure it doesn’t break anything we’ll need to extend our tests to cover many more use cases than we’ve got today for all supported package managers, which is quite a bit of work. I’ve started adding tests but I am not done yet. I have even considered releasing a separate package with the redesigned approach to hooks management, but it seems to be overkill to fork and maintain a new repository to only fix one issue.

I am using husky in most of my monorepos myself and though, as @fixpunkt has correctly pointed out, “being able to just run yarn install from any place in the monorepo” is a valid use case, I think the best workaround, for now, is to avoid running yarn install and similar commands from anywhere except the repository root.

@dcastil’s solution fails if the build from inside the package. E.g. Netlify does this for monorepos. A slight adjustment to get it to work is:

"postinstall": "if [[ -f ../../.git/hooks/husky.local.sh ]]; then sed -i '' -E 's/cd \".+\"/cd \".\"/' ../../.git/hooks/husky.local.sh; fi" }

My setup is almost identical (using Yarn workspaces only, no Lerna) and I’m getting the same. This is what my structure looks like:

package.json (Husky setup at root)
- packages
  - client
    package.json
  - server
    package.json

I just did some testing and it’s only happening with the yarn remove ... command, and not with yarn add ....

Changes the husky.local.sh from this (which works fine):

packageManager=yarn
cd "."

to this (the hook stops running on commit):

packageManager=yarn
cd "packages/client/"

@Ashoat we found that if you upgrade to husky v6 it fixed this

@JonKrone can you please merge #728. I added testing instructions.

I didn’t test it sufficiently, but it seems like husky saves the location from which the initial yarn install was run after husky was added by someone else in .git/hooks/husky.local.sh. E.g. if the initial yarn install was run in packages/web-app, it contains a line like this:

cd "packages/web-app"

which needs to be changed to

cd "."

in order for husky to run properly.

My workaround for this is to add a postinstall script into the package.json of all workspaces:

{
  "scripts": {
    "postinstall": "sed -i '' -E 's/cd \".+\"/cd \".\"/' ../../.git/hooks/husky.local.sh"
  }
}

Hey, just wanted to ping this thread to make sure it doesn’t get closed as stale. We’re experiencing this issue with Yarn Workspaces and would love to see it fixed.

I commented back on the patch PR https://github.com/typicode/husky/pull/728 - I think it is ready to merge.

There is a special node on using husky with monorepos: https://github.com/typicode/husky#monorepos In short for monorepos, it is recommended to only install husky into the root package. Otherwise, all sorts of conflicts are expected when husky installation script is run for several packages in the repo.

I use husky with lerna and yarn workspaces by installing husky to the root package via yarn add --dev -W husky. The -W/--ignore-workspace-root-check flag allows installation into the root package (https://classic.yarnpkg.com/en/docs/cli/add#toc-yarn-add-ignore-workspace-root-check-w). Personally, I haven’t seen any downsides of this approach so far.