Configuration files, npm modules and lost sleep — why publishing front-end modules is painful, and how to make it fun again
Then the actual fun begins.
You realize your little file has grown into the hundreds of lines, so you decide to split it up into modules so you actually have a chance of maintaining it in future. Now all of a sudden you need some kind of bundler, so you dust off webpack and desperately search for an old config file to copy, so you can unlock webpack’s secrets and create a nice minified script to distribute.
Next, you realize you want to target older browsers, so people can actually use your code . You’ve written in ES2015 features like let, arrow functions, and object destructuring, which probably work in the newest versions of Chrome, Firefox and Safari but none of the older browser versions (which you totally forgot to test in). So you layer on Babel, eventually get it configured in a way that seems to work, and you compile everything down to ES4 at build time.
After a few seconds congratulating yourself, you realize people are going to freak out if you release any kind of open-source code without including at least a few tests, so you break out Mocha and start writing some, because you forgot to start with test-driven-development (again).
After a while, you realize that running your tests in plain old Node isn’t going to work, because you’re using a bunch of browser-specific apis and features, and you don’t really want to mock all of them out. So you break out Karma and PhantomJS (or Headless Chrome), and throw your tests into a real browser to get them passing — that is, once you figure out how to get Karma to play nicely with Babel.
Suddenly you realize you have no idea how much of your code your tests are actually covering, so you figure: let’s throw in some code coverage tooling and find out! You add in istanbul, and after wrestling to get that, Babel, and Karma to all play nicely together, you save your latest ungodly mess of configuration files, and grab another cup of coffee.
You decide that now you have all of these tests, you might as well actually run them in some kind of CI, otherwise they’ll probably never get run. So you desperately hunt for an old Travis config file you can copy into your project, and tweak it to work with your codebase.
After all that, you realize that even with good tests, people are still going to make pull requests to your shiny new open-source module with changes that don’t follow your coding style, or worse, code that introduces subtle bugs. So you add in ESLint and configure a bunch of rules to make sure any new code follows the style of your existing code. If you’re lucky, maybe you’ll even catch a few bugs at build time for good measure.
Catching bugs at build time makes you greedy for more static analysis. Let’s catch even more! So you decide to try adding Flow (or TypeScript), and then you go the whole hog, static-typing all of your code and destroying null pointers before they even get a chance to rear their ugly heads.
You now have about a million build-time tasks, so you do what all the cool kids are doing and group them into some handy npm tasks.
Finally you’re ready to release your code! — but … it’s late, and you’re sleepy, so it’ll have to wait until tomorrow.
I was finding myself spending way too long doing this. So I threw together a boilerplate module called
grumbler, which I believe combines some of the best build tools out there, allowing you to just write code and forget about the details of building and distributing.
- Fork it
- Start coding!
If you do like setting up your own build, or you have your own specific choices for which tools to use, this module probably isn’t for you. But for everyone else, if you want to save time researching and integrating all of this stuff, grumbler might help kick start your project with a pretty small amount of effort.