It’s so tempting and easy for you to do something that might potentially cause you a LOT OF HEADACHE LATER ON! A tutorial might tell you to do it, or maybe you just want to use ES6 inside of Node REPL… Whatever your reasons, do not ever do the following if you are a developer:

npm install -g babel

Also, anything that would allow you to write ES6 without warning in your environment might cause significant problems later.

In fact, if you need to install server stuff, like http or webpack, you may have to install some global npm packages on your machine, but always remember that your app may be relying on these global packages in development, and then magically not have them on production. However, the whole time you have not had any problems, b/c you had a global dependency that was being utilized by node rather than a project wide dependency, like you should always be using. So, beware any

npm install -g 'whatever'

Ill tell you how I found this out…

Recently, I wrote an ExpressJS API for a popular web tutorial front-end. I was happy with my work, and tested it, I had thought, thoroughly. But then when I tried it on Safari, it didn’t work. I struggled to find the bug, but Safari has crap developer tools and gave up initially. Usually these things work themselves out.

So, I wound up deploying this app on a server, and realized, I had some ES6 code in my Express files. Now, express does not use ES6 by default. So, you can hopefully see the issue.

I had ES6 interpreter on my machine via npm packages, and those were not present in the production app, nor should they be.

I caught the problem and have updated the code to Yodagram, and taken out all of the ES6. This means string literals, short-handed object assignment, i.e.

const code = req.body.code;
const obj = {

Now changed to…

var code = req.body.code;
var obj = {
    code: code

Basically, I was not catching all the errors that my leftover syntactic sugar should have been causing, and didn’t realize it until I had to use my server to revert to plain JavaScript one error at a time.

So, the message is, beware of using global npm packages on your machine. There are very few that you actually need. And if you do, remember if you encounter a problem like this, it might be because you have some global packages on your machine that are allowing you to get away with things that your production environment will not unless you alter it.

If you need a REPL sandbox, make a new directory and install npm modules in that. Call it node-sandbox if you want, and you can install all the npm packages you want in there, without adding confusion with global package installs

So, beware npm i -g 'anything' unless you absolutely have to…

Hack on!


Share on FacebookEmail this to someoneTweet about this on TwitterShare on Google+Share on LinkedInShare on Reddit