ES Check, a lil’ JavaScript utility that will save your butts

Published in

DSC Engineering

4 min readSep 26, 2018

JavaScript is everywhere when it comes to software development. It can be used for building apps, web pages, on servers, or in little robots 🤖! How can we make sure your JavaScript is capable of running everywhere you want it to as we’d like it to?

Well, that’s what ES Check does! It’s a utility that was written to ensure that the version of JavaScript going to production matches an expected JavaScript version for production.

ES Check takes 2 steps to set up!

Setting up ES Check can be done by installing it and adding a 1 line script.

Add ES Check.

npm install es-check --save-dev

2. Then add a script like the example below.

"test:es-check": "es-check es5 'dist/*.js'"

Using the example above, JavaScript can be tested to match the specified JavaScript version by runningnpm run test:es-check in a command line. That’s it! 🎉

Why does knowing that JavaScript matches a specific version matter?

If compiled JavaScript doesn’t match a supported JavaScript version of the environment it is in, it won’t work. This is bad! Providing web pages, apps, services, or robots with unsupported versions of JavaScript can cause them to work partially or fail. 🙀

How do JavaScript version mismatch problems occur?

“You should have checked your compiled code before it went to production!”, you say? I do! I did! I swear!

JavaScript version mismatch problems can arise unexpectedly with modern code release infrastructures. In a few paragraphs listed below, I will describe to you how this s**t show arises. Keep note, I am dramatic! 🤷🏽‍

Pre-s**t show required awareness

Here’s a quick code snippet of a fake package.json with 2 *devDependencies[1], foo and bar.

"devDependencies": {"foo": "^1.2.4","bar": "^6.0.1",
}

Notice the ^? Well that ^ tells npm, if there is a slightly newer version of foo or bar, install that version. So even though foo suggests that it is using 1.2.4, it may actually be using 1.2.6.

Here’s how the s**t show happens

Let’s say there are some updates to foo. foo has some of its own devDependencies updated and a bug is fixed. foo version 1.2.7 is then released.
I, meanwhile am testing some of my code. I’m usingfoo 1.2.6 and it works for me in my testing environment.
Everything looks good so I push my code to production.
In the process of building my code for production, my new build gets foo 1.2.7 which was just release because of that ^.
Because of foo's devDependency updates which were added with a bug fix, it’s build has changed unexpectedly.
foo's *patch[2] version 1.2.7 build changes cause the bundle of JavaScript to my production build to compile with foo containing version JavaScript I’m not expecting.
The environment that I’ve just pushed JavaScript code to doesn’t support the version of JavaScript in foo that I just sent to it and promptly shits itself.
A team member or worse yet, a customer let’s me know that my code that went to production is shit. I cry and I figure out the bug and try to pass the buck on foo but no one cares because I’m right there, ripe for all of the blame.
I pin foo to 1.2.4.
I push to production. Everything is fixed—except me. 😿

Glossary

devDependencies: helper JavaScript code that someone else wrote that I use to get s**t done faster. 💨
patch: a version change that is expected to fix an issue but not break the existing functionality of a package.

Wrapping it up

After I’d had enough of describing how each failure occurred, I decided to re-think the problem. I made ES Check to put that problem to bed. ES Check uses the Acorns JavaScript parser that verifies JavaScript versions.

There are a few more features I’ll be adding to ES-Check and contributions are welcomed. I’ve even been able to use it to report bugs fast to open source projects I use. Use ES Check for your projects and especially for your open source projects to protect yourself from s**t shows and save your butts!

I got a lot of help from the engineering team at Dollar Shave Club writing ES-Check, this article, and at life—it’s tough. The team at Dollar Shave Club is awesome. We believe in the products we’re building. If you’d like to join the club, go here. If you’d like to code with us, go here. If you’d like to work with us, go here. Follow us on Twitter.