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.
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.
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.
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.
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.
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.
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’.
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
- A Guide to the React Ecosystem
- 50% off React in Action Today
- A Conceptual Introduction to React Components
- I'm writing a book about React!
- Type Inspection In Go
- Testing React Components with Enzyme and Mocha
- Start Simply, Simply Start
- Using Event Emitter in Node.js
- React Native: Quick Start and Including Images
- New NPM Module: Favorites
- Running Node.js Apps in Production
- Server-Side Rendering with React and React-Router
- Installing iojs and Node.js Together
- Get Functional