Hi!
I think we should stop using make files and use npm scripts or gulp instead.
This way the test process will be accessible for windows users (me 😅).

What do you say?

After digging around I found that, for example, in '../path/to/project/.git/hooks/commit-msg',
the script template had set node_modules paths as:

var nodeModulesPath = '/Users/apollotang/Desktop/webpeck-deep-dive/v01/es6-todomvc/node_modules';

Meaning, if I relocate project folder from ~/Desktop to ~/Projects, I will no longer able to do git checkout unless I manually edit nodeModulesPath in every hook in .git/hooks to:

var nodeModulesPath = path.resolve('../../node_modules');

Or alternately, start all over to regenerate new node_modules path.

I'm thinking something like this:

{
  "ghooks": {
    "commit-msg": "node do-something.js $2"
  }
}

The resulting executed command:

node do-something.js .git/COMMIT_EDITMSG

This is handy for utilizing the arguments normally passed to .githooks.

I have hacked something together as a proof of concept. I'll open a PR for it (don't have time to make tests for it right now).

This is how I would love it to work:

• On install create .ghooks or hooks folder or similar on project root
• Have a plain bash file if [ -e "../../ghooks/$hookname" ] as hook in .git/hooks

This way we remove the need of any configurations file, we can use whatever language we want, we can have developer specific .env files to fix gittower alike GUI problems and all hooks are explicitly versioned and only in one place.

Also we could probably use symlinks in .git/hooks since it's the same file over and over.

I have installed ghooks and setup the config in my package.json like so:

...
 "config": {
    "ghooks": {
      "pre-commit": "gulp",
      "post-merge": "npm install"
    }
  },
...

The gulp task contains unit tests and linting; when someone commit's, gulp now runs - but the commit still works even if the gulp task outputs errors. I would like to setup the repo so that a user cannot commit until the gulp task (unit tests, linting etc.) passes without any errors; is there a parameter I can pass to do this or something? I don't see any information in the documentation...

When installing under a git submodule, installHooks() correctly finds a .git folder (for the submodule), but can't resolve(gitRoot, '.git/hooks'), resulting in the following error:

fs.js:747
  return binding.mkdir(pathModule._makeLong(path),
                 ^
Error: ENOTDIR, not a directory '/testproject/submodule/.git/hooks'
    at Error (native)
    at Object.fs.mkdirSync (fs.js:747:18)
    at ensureHooksDirExists (/testproject/submodule/node_modules/ghooks/lib/install.js:78:38)
    at installHooks (/testproject/submodule/node_modules/ghooks/lib/install.js:41:5)
    at Object.<anonymous> (/testproject/submodule/node_modules/ghooks/bin/install:3:1)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Function.Module.runMain (module.js:501:10)

I have a script in a scripts folder that I want to run as my post-update hook. Is there any way I can accomplish this without having:

"post-update": "chmod +x scripts/post-update-install && scripts/post-update-install"

in my config?

That script is @sindresorhus script here: https://gist.github.com/sindresorhus/7996717

This module, even as a dependency of another module, infiltrates the parent .git folder and installs git hooks that are broken and/or platform dependent. The fact that you have another issue related to incompatibility with GUI git clients, and that you suggest changing how those clients are launched, is absolutely ridiculous.

This module is worse than broken -- it's a hazard to other projects that causes mysterious failures. A node module should not be manipulating such critical files in such a sloppy way. Frankly, this whole project should be disabled and/or banned from the NPM registry immediately.

Following is the erros:

[email protected] install C:\xampp\htdocs\qui_1\q-municate-web\node_modules\ghooks
node ./bin/module-install

npm ERR! Windows_NT 6.3.9600
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "install"
npm ERR! node v4.4.7
npm ERR! npm v2.15.8
npm ERR! file C:\Windows\system32\cmd.exe,;C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\cmd
npm ERR! path C:\Windows\system32\cmd.exe,;C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\cmd
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn C:\Windows\system32\cmd.exe,;C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\cmd

npm ERR! [email protected] install: node ./bin/module-install
npm ERR! spawn C:\Windows\system32\cmd.exe,;C:\Program Files (x86)\Git\bin;C:\Program Files (x86)\Git\cmd ENOENT
npm ERR!
npm ERR! Failed at the [email protected] install script 'node ./bin/module-install'.
npm ERR! This is most likely a problem with the ghooks package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node ./bin/module-install
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs ghooks
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR! npm owner ls ghooks
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! C:\xampp\htdocs\qui_1\q-municate-web\npm-debug.log

What do you think of this? Given:

{
  "scripts": {
    "pre-commit": "eslint src/"
  }
}

ghooks would run:

npm run pre-commit

This would make #26 unnecessary for my personal use case (though still handy probably).

The one thing that I can't quite figure out is how to still support #23 with this... In the case of #23, I would expect the arguments to still get forwarded on:

{
  "scripts": {
    "commit-msg": "validate-commit-msg $1"
  }
}

ghooks would run:

??? how does it forward on the arguments

So, for cases where the arguments are needed, you'd probably still have to use the ghooks in config....

After having written this, I'm questioning whether it'd be worth it. Thoughts?

The git hook template should somehow try and catch on a require('ghooks') to prevent the case where someone deletes their node_modules directory and tries to pull. Had this cause some trouble for me. We could have it warn that the hooks aren't running.

http://stackoverflow.com/a/7230886/2792217

Due to the way hooks are configured with ghooks, the --no-verify or -n option to bypass the pre-commit hook will not be functional. Some people may consider that a good thing ;x.

Not sure if you'd like to just document this in the README, or if you want to try and fix it.

I've updated ghooks to be automatically released whenever something gets merged into master with the proper commit conventions. This follows my series using semantic-release to manage the releases. Please see CONTRIBUTING.md for more info :-)

#166 deprecated ghooks in favor of husky. Husky used an opinionated approach to managing hooks using the scripts object in the manifest instead of config which causes:

• All those migrating must change their package manifest
• All those migrating must use scripts to define their hooks

I opened a issue in Husky requesting backwards compatibility and it sat for 20 days without response. Here's the issue, which contains some additional info and justification for not using scripts: typicode/husky#133.

The purpose of this issue is to revive ghooks from deprecation. Initial thoughts are:

• Create a 2.1 release which allows users to define hooks config in a pkg.ghooks object at the root of the package manifest with full backwards compatibility with the pkg.config.gooks object. The pkg.[package] approach is used by libraries such as Standard JS as config is typically reserved for NPM use (though it's sometimes used by other packages).
• A more radical idea is to fork Husky, create ghooks 3.0 with backwards compatibility with the benefits of whatever Husky is providing which makes others want to use it over ghooks.

/cc @duclet @ta2edchimp @gtramontina @kentcdodds for thoughts

Unless I'm mistaken... But I think we should move opt-cli to a devDependecy. No reason to install it on other people's machines I think.

I think it could be useful to have a list of actions that could be ran on a specific hook. For example, I could have a config section in the following format:

  "config": {
    "ghooks": {
       "post-merge": ["hooks/check-file-changes.sh", "hooks/verify-asset-checksum.sh", "hooks/whatever.sh"],
       "post-rewrite": ["foo.js", "bar.lua"]

and it would call the respective files listed in the array, in order.

Do y'all think that would be useful?

[email protected] > [email protected] > [email protected]

cross-spawn-async requires a build toolchain. So moving to execa @ 0.4.0 which uses cross-spawn @ 3.0.0 you remove the need at least in this instance for a compiler. This should allow the package to install faster and also make it compatible with more environments.

With the new System Integrity Protection scheme of El Capitan (http://apple.stackexchange.com/a/193379), the common workaround for getting #!/usr/bin/env node to work on OSX is no longer valid. Although this is technically not an issue of ghooks, it does render the module useless. Any thoughts?

I'm using ghooks for several projects but for one project I decided to uninstall it.
After npm un ghooks I'm getting error on every commit:

ghooks not found!
Make sure you have it installed on your "node_modules".
Skipping git hooks.

Is it possible to cleanup modified hooks automatically?
thx!

Hi @gtramontina,
Thanks so much for creating ghooks, our team use it every day and find it really useful.

There's one small issue though regarding support for GUI Git Clients such as Tower;

Searching for a fix, it looks like similar projects have also had this problem.

(I don't think this is environment related, but some output if needed)

$ /usr/bin/env node --version
v0.12.0

$ which node
/usr/local/bin/node

$ echo $PATH
/Users/jmason/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

I hope this is useful, thanks.

Regarding current issues ( #70, #71 ), it may be worth thinking about introducing a next release channel.
I had a quick look into how semantic-release does their own publishing of versions:

They have three (publicly accessible) branches:

1. caribou is the one, all Pull Requests are compared to and merged into.
   It has the publishConfig field, pointing to "tag": "next".
   Releases made from this branch are labelled Pre-Release.
2. badger is the one that the non-Pre releases are made from, its package.json has no publishConfig field, thus pointing to tag latest.
3. alpaca is the one I, at a first glance, do not have the slightest clue about what it does. Its .travis.yml's deploy section seems full of an ancient dialect even my great-grandfathers did not speak anymore.

Maybe we can copy that behavior:

• making the current master our caribou (for next tagged pre-releases)
• create a new branch stable or sth like that to become our badger (for the latest tagged ready-for-production releases) to merge into from master regularly (to be defined).

What do you think?

Hi. I was wondering if you would know of a way to configure ghooks to only trigger the pre-push action for a specific branch, specifically master.
My use case is the following:

   "ghooks": {
      "pre-push": "npm run coverage && npm run coverage:check"
    },

In this scenario, I use pre-push to stop anybody (mostly myself) from pushing when the code coverage is below a specific threshold. However, I'd like to restrict this safety check to master only -- it is OK to push to a work-in-progress branch, even when the coverage is low (assuming that it will get better by the time it's ready to merge it with master).

Thanks!

Hello,

I had, like some other people on the gitlab community (see here) an issue with the post checkout hook that is automatically created with the node shebang on top of it.

I wonder if it's possible to add a shell script before the execution to check that the node executable is on the path... and otherwise, gracefully exit, maybe with a message or with an option on the package json configuration.

I offer myself to help you out with this if we agree on a solution.

Hey friends! So I recently found another similar module called husky. I've tried it on a few of my projects and really like it. Here are a few reasons I think it'd be great to deprecate ghooks and put our efforts behind husky:

1. It's good to merge projects/choose a "winner" when that can reasonably be done and focus efforts
2. They support git GUIs #40
3. Config is slightly simpler

Thoughts? 💭

Hello,

I am using the ghooks package as part of another package and noticed a small issue. When trying to run git commit, I was getting an error saying:

"." is not recognized as an internal or external command, operable program or batch file.

I was able to do everything but commit to this project. I was able to pin down the source to the runner.js. Since my hooks are located inside C:/.../.../ProjectDirectory/.git, windows was trying to execute this hook with a "." in the path and it was confusing it. I have a fix for it but wanted to open an issue.

I was just curious why there aren't more hooks available for this? I don't currently have any particular reason for any specific additional hooks, but it just seems odd that you limited the set. For example, why not post-commit?

npm install ghooks fails in node 0.12 because of the use of const in the install script:

> [email protected] install /tmp/node_modules/ghooks
> opt --out ghooks-install --exec "node ./bin/install"

/tmp/node_modules/ghooks/node_modules/path-exists/index.js:2
const fs = require('fs');
^^^^^
SyntaxError: Use of const in strict mode.
    at exports.runInThisContext (vm.js:73:16)
    at Module._compile (module.js:443:25)
    at Object.Module._extensions..js (module.js:478:10)
    at Module.load (module.js:355:32)
    at Function.Module._load (module.js:310:12)
    at Module.require (module.js:365:17)
    at require (module.js:384:17)
    at Object.<anonymous> (/tmp/node_modules/ghooks/bin/install:2:16)
    at Module._compile (module.js:460:26)
    at Object.Module._extensions..js (module.js:478:10)
npm ERR! Linux 4.4.0-22-generic
npm ERR! argv "/home/geraint/.nvm/versions/node/v0.12.14/bin/node" "/home/geraint/.nvm/versions/node/v0.12.14/bin/npm" "install" "ghooks"
npm ERR! node v0.12.14
npm ERR! npm  v2.15.1
npm ERR! code ELIFECYCLE

dcc01d2 introduced an error return value for when ghooks is not found.

This is a really bad idea, since git commands start failing whenever the node_modules directory is not populated. This started breaking our (Microsoft/vscode) integration.

I believe the previous behaviour of warning the user was the best one.

I did everything according to the readme instruction, but still got the warning 'Make sure you have it installed on your "node_modules"'.

I also tried to require ghooks in the project path, and it seems like it is installed correctly.

> var ghooks = require('ghooks')
> ghooks
[Function: run]

When ghooks is installed as a dependency using npm@"^2.0.0" (as done here), its own dependency opt-cli cannot be found when running the install npm script.

I know this is a weird issue, but I've just encountered that using --work-tree (as in git --work-tree some/folder commit) causes ghooks to blow up with the following:

$ git --work-tree ./foo commit -m 'an example of --work-tree crashing'
module.js:339
    throw err;
    ^

Error: Cannot find module '<snip>/ghooks-test/foo/package'
    at Function.Module._resolveFilename (module.js:337:15)
    at Function.Module._load (module.js:287:25)
    at Module.require (module.js:366:17)
    at require (module.js:385:17)
    at commandFor (<snip>/ghooks-test/node_modules/ghooks/lib/runner.js:17:13)
    at run (<snip>/ghooks-test/node_modules/ghooks/lib/runner.js:8:17)
    at <snip>/ghooks-test/.git/hooks/pre-commit:7:20
    at Object.<anonymous> (<snip>/ghooks-test/.git/hooks/pre-commit:8:3)
    at Module._compile (module.js:435:26)
    at Object.Module._extensions..js (module.js:442:10)

I think it's a case of simply try/catching and just cracefully failing if the package.json cannot be found. I'm happy to work on a PR if you're happy to accept one?

FYI if you're thinking "what in the world are you using --work-tree for?!" - well, I'm trying to have a gh-pages branch which tracks my site directory (rather than repo root) - using https://github.com/lukekarrys/git-directory-deploy

When I run $ npm install ghooks --save-dev I get:

fs.js:438
  return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
                 ^
Error: ENOENT, no such file or directory '/Users/kentcdodds/dev/genie/.git/hooks/post-update'
    at Object.fs.openSync (fs.js:438:18)
    at Object.fs.writeFileSync (fs.js:977:15)
    at install (/Users/kentcdodds/dev/genie/node_modules/ghooks/lib/install.js:36:6)
    at Array.forEach (native)
    at installHooks (/Users/kentcdodds/dev/genie/node_modules/ghooks/lib/install.js:19:31)
    at Object.<anonymous> (/Users/kentcdodds/dev/genie/node_modules/ghooks/bin/install:3:1)

This is because I have no hooks directory. On my team, I don't want to have to ask everyone create a hooks directory every time they clone the repo. I'd much rather have this just work smoothly. Any chance that we could have this create the directory if it doesn't exist using mkdirp or something?

Hi!
Is it possible to add hook for git svn dcommit command?
It would be great!

The ghooks is working on terminal.But it failed with srouceTreeApp

System: mac os
error : env: node: No such file or directory

git allows to create more than one worktree connected to the same repository (.git/) via the git worktree command.

In each of this worktree there is a .git file containing the path to a directory inside the main .git/, e.g.:

gitdir: /home/julien-f/dev/my-project/.git/worktrees/my-branch

This is something of an edge case so I would understand if you do not want to support it :)

I think that we could potentially fix the issues with GUIs by making the githooks use the system's default shell scripting language (not sure what it is for Windows). Then it would set the PATH and call into the node stuff. Thoughts?

Looks like in the install.js script it's looking for the node_modules directory and calling that root. Couldn't it look for the .git directory instead? Or am I understanding this wrong?

Installation failing. NPM 2 is old and does not use flat file structure. Let's drop support.

Related discussion: #71

There are a few jshint entries related to code style that are getting deprecated and it is suggested the use of jscs.

We could take this opportunity to revisit tooling and styles/preferences or we could simply go with presets like eslint + a preset, or even xo or standardjs.

💭?

If you npm install ghooks over and over again, your .git/hooks/ directory will fill up with pointless .bkp files. Would be cool if this read the file to determine if it's ghook's hook.

I need to be able to set project root manually.

The directory structure I have is

git_root\frontend

where git_root contains .git and frontend contains package.json where I run npm

When I run <git_root>\frontend\npm install I get "This does not seem to be a git project"

Just like npm-scripts do:

In addition to the shell's pre-existing PATH, npm run adds node_modules/.bin to the PATH provided to scripts. Any binaries provided by locally-installed dependencies can be used without the node_modules/.bin prefix. For example, if there is a devDependency on tap in your package, you should write:

"scripts": {"test": "tap test/.js"}
instead of "scripts": {"test": "node_modules/.bin/tap test/.js"} to run your tests.

This would be very handy!

Does anyone have a git commit hook I can use that will ensure a JIRA issue number appears in the checkin message?

Allow the user to specify they'd like to only run the hooks if a certain file is present. This file is gitignored so you opt-in by creating the file (and maybe it should have contents, like which hooks to opt-into).

This would make it easier for beginners to start contributing by removing barriers until they're comfortable with the project and contributing regularly.

I'm receiving this even when I installed everything even globally.

ghooks not found! Make sure you have it installed on your "node_modules". Skipping git hooks.

package.json
"config": {
    "ghooks": {
      "commit-msg": "validate-commit-msg",
      "post-merge": "npm install"
    }
  }

The link to the angular style conventions in CONTRIBUTING.md returns 404.

Alternatives:

• Angular's contributing.md, section git commit guidelines
• Angular's google doc on the subject

package.json get's published to npm and other registries, other than being a really intimate place for most projects. There should be an option to read .ghooksrc first.

For example I don't even have a config section in my package.json.

Because missing ghooks is similar to a hook failing.

Therefore: process.exit(1).

If ghooks is installed in a project that isn't a git repo, it helpfully prints out a warning (https://github.com/gtramontina/ghooks/blob/master/lib/install.js#L68). However, this line is incorrect:

Run "git init" and then "npm run ghooks install"

npm run hasn't been able to run dependencies' scripts since npm@2 (npm/npm#9186). The workaround is to instead run npm explore ghooks -- npm run install.