Elastic Beanstalk NPM production installation tips

Elliot Blackburn
Engineering on the incline
2 min readJan 12, 2018

We recently tried to deploy the latest version of Gurn using the NODE_ENV flag set to production, at first glance this makes sense. We’re now on production, so we want to make sure that everything acts as if it’s in production. However this causes issues when working with gulp and typescript.

We currently run our TypeScript build inside the Elastic Beanstalk deployment steps, just before starting up the application. We do this via gulp.

The error we were getting was:

[11:55:22] Local gulp not found in /var/app/current
[11:55:22] Try running: npm install gulp
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! @gradient/gurn-api@1.0.3 start: `gulp && node ./dist/index`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the @gradient/gurn-api@1.0.3 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Our environment had NODE_ENV set to production and NPM_USE_PRODUCTION set to false. The NPM_USE_PRODUCTION environment variable is one added by Elastic Beanstalk and acts only to ask whether to add the --production flag to the NPM install step. However, as stated in the NPM docs

With the --production flag (or when the NODE_ENV environment variable is set to production), npm will not install modules listed in devDependencies.

As it turns out, the NODE_ENV actually takes priority, meaning gulp and our TypeScript types were not being installed, and thus gulp did not exist locally.

We’ve decided to use NODE_ENV=live now instead of production, this will help us avoid that default behaviour but ensure we still have something to hook onto in our system to see if we’re on a customer facing server.

The ultimate goal that we will now strive towards is building from TypeScript to JavaScript on our CI (circle-ci) and then shipping that over to Elastic Beanstalk, we’re just not there yet!

--

--