3 Essential NPM Packages

I’ve been writing up a lot of little Node projects recently and there’s a few npm packages I’ve come to rely on for code quality. I figured I’d write them up so others can use them. I’d also love to hear from you about the packages you consider essential for npm, so please leave a comment!


Pre-commit hook

A pre-commit hook is essential to enforce your code standards before committing. While CI tools mean you can and should run your checks on the build, it’s best practice to run before commit — vastly lessening the chances of errors making it into your repo.

I’ve used pre-commit very happily in my projects, although there are other tools as well.

Usage:
I have configured it to run my code coverage tool (see below) and eslint. I deliberately removed some of the test coverage, and tried to run git commit -m ‘pre-commit demo’.

Commit failed since my test coverage was not high enough.
Proof that the commit failed — latest commit is not the one I tried.

eslint

At first, eslint is the biggest pain in the ***. But with a little bit of configuration and patience, you’ll find that it does way more than make your code cleaner: its rules about the code itself mean you will learn so much about JavaScript, particularly if you are new to ES6. Configure it to run on your pre-commit hook to get the full benefit.

Note `unusedVar` on line 7.
We get these errors.

The first few times you use it, you’ll find it slows you down. However, the benefits become apparent pretty quickly.

You can also configure it pretty easily as needed, and even choose a popular style guide so you don’t have to spend too much time yourself. Run eslint — — init to kick off the configuration.

Recommended Resources:

AirBnB’s style guide for eslint — really interesting reading.

JSJ 336: “The Origin of ESLint” with Nicholas Zakas — great podcast

NYC — code coverage tool

Why a code coverage tool? First of all, to enforce test coverage. I have it set to 95% and I can’t make a commit if I don’t have that amount of coverage. However, it’s also super useful when refactoring tests to make sure you haven’t accidentally removed the only test covering a particular line of code.

Message from NYC.

As you can see, the messages are very helpful, particularly which lines are uncovered. I can pinpoint exactly where I need to sort out the tests. Make sure to tell it to exclude the test files so you don’t get stuck in an infinite loop of coveage errors!

Recommended Resources:

NYC npm package

Conclusion

Automate whatever you can, including your code quality tools. It’ll drive you up the wall at first but it’s worth it. If you want to see these tools in action, check out my CocoaJavaScript repo (currently a work in progress to create parameterised testing in JS/Mocha).