Npm Modules I can't live without (pt. 2)


3 minute read


I’ve been writing a three-part series on some great modules I love and use. This is part two, but make sure to check out the first post.

  1. Eslint: If you’re not doing static analysis on your code, you’re carrying around a giant foot-gun…and probably using it, often. Eslint comes from the jsHint/jsLint school of thought, but with some notable differences: Espree for parsing, an AST for analysis, and it’s very pluggable. Every rule is essentially a plugin.

  2. Gulp: If you’ve been doing anything more than the very simplest of sites, you’ve probably found that the number (and size) of tools required* for front-end (or back-end) web dev has gone up substantially. Grunt is/was cool, but gulp comes in and brings streams to the table. This means no more tmp-ing everything up, just transforms applied to input to give you output. Not to mention the concurrency gains.

  3. Babel: The next version of JavaScript (ES6/ES2015/jsNExt/Oooo Arrow Functions!) has finally been finalized. So now, we wait for all browsers and runtimes to support it, right? Wait, there’s an epic transpiling library that’s essentially wiped out any and all similar projects in it’s path? Yes, yes there is. Babel will let you ES6-ify all of your code and allows for pretty good feature usage & support. You can’t use some of the less-polyfillable features all the way, like Symbols and true tail-call optimization. But that’ll come in time. Write modern JS!

  4. PM2: When I was first getting into working with Node, I came across a few modules that seemed really useful for running a Node app on the server (Forever, nodemon, &c.). They were and are great, and definitely solved a huge set of problems, like, say reliably running a node process. Kinda important. But when I found PM2, things were kicked up a whole notch. The project has become, arguably, a little bloated (lots and lots of features), but it still does one thing well: run your node processes in production with high reliability, accessibility, and tunability.

  5. QS: Who’s ever been excited about parsing three-deep nested query strings? Someone, maybe. But it’s pretty much just them. QS frees you up to focus on the more meaningful and challenging parts of your application.

  6. Socket.io: WebSockets are one of those things you’ve probably heard about and played with a bit, but never had to put something into production with. Or maybe you have, I don’t know. But if/when you do need to, you’ll want something like Socket.io to help you deal with all the sockets. It’s not code that no-one else can write, but it’s code that you don’t want to have to re-write unless you have really specific needs for an interface or are dealing with huge scaling concerns.

  7. Request: Every language has ‘that one http library’. This is the most well-known, although not the most lean one. Definitely up there with Lodash in terms of being ‘most depended on’.

  8. Faker: A huge part of doing good testing is using good (variable, improbable, sometimes-mundane) test data. Faker lets you generate ‘massive amounts of fake contextual data’. This is yet another case where you could probably write something similar, but why?

*Read super helpful, but not absolutely necessary

Related: