SVN JSHint Hook?

Question

I have been searching in Google and on here but have not found a relavant answer. The project I am working on is using SVN. The question I have is wondering if anyone has implemented a pre-commit hook that will stop the check in if JSHint fails?

Thank you for anyone who has experience doing something like this.

Answer 1

I would not make this a pre-commit hook because of the length of time that JSHint takes. When someone does a commit, they'll have to wait for JSHint to complete and wait for the verdict.

Remember that Subversion hooks run on the server and not the client's machine. That means your pre-commit hook has to do a checkout, and then run JSHint. Even if this takes only 30 seconds to perform, it's 30 seconds the developer is sitting there waiting for the commit to finish and having their hatred for you, the company, and Subversion grow. Plus, if something happens to the hook that causes it to fail, you'll have to debug it and fix it while developers will be unable to commit their code.

Your developers will quickly grow to hate you and Subversion and may even take the step of setting up their own source repository. I've seen this done back in the days when ClearCase ruled and Subversion was first created. Developers setup their own repository with Subversion (since it was easy to do) and stopped using the corporate ClearCase repository.

Instead of a pre-commit hook, use a continuous build engine like Jenkins.

When someone does a commit, Jenkins will do a checkout, and then run whatever tools you need (like running JSHint). Later on, you might want to expand what tools you want to use. You can even have Jenkins create a deployable artifact (like a zipfile). Jenkins will gather your history, show you the changes between commits, and let you know who did what changes.

But, you ask, without a pre-commit hook, won't developers be able to check in code that causes JSHint to fail?

Yes, they can. However, you can configure Jenkins to notify you and the developers when this happens. Since this is version control, it's easy to have the developer fix the issue or undo their commit.

The trick is to shame the developer who broke the build. Stockades and a supply of overripe tomatoes are good. A dunce cap and a big sign that says "I broke the build" will also work. Maybe a big scarlet B for Build sewn onto their clothes.

Actually, developers will naturally not want to break the build. It makes them look bad and unprofessional. Developers will get into the habit of running JSHint themselves before they do their commit which is exactly what you want to happen.