Setting up package.json for easy deployment

Lambda functions often require a set of standard parameters during creation, such as security policies, non-standard timeouts or memory limits. Keeping those parameters outside the project code is error-prone, as people can make stupid mistakes during deployment. This is particularly important for effective teamwork. Also, when a team is running multiple versions of the same function for development, testing and production, it’s important that everyone remembers how individual versions are called.

A useful trick to automate such steps and avoid common problems is to store standard deployment arguments in NPM package scripts. That way, all the developers on a team will instantly have the same configuration. This is also very useful if you plan to publish your Lambda microservice as an opensource project, so that all anyone who installs it locally knows how to set it up easily. Running Claudia from NPM scripts also allows you to keep it local to a project, instead of having to install it as a global utility.

Setting up deployment scripts

First, install Claudia as a development dependency in your project. The -D flag will save the reference to Claudia in package.json, so the all the other collaborators get the same version when they install the package.

npm install claudia -D

Next, in your project package.json, find the scripts section (or create it if it does not exist), and just add a few key-value pairs to it. The key is the name of the script (for example deploy). The value is the command you want to run, with a slight twist. You can use any locally installed NPM command as if it were in the system path. For example, the following script will create a new Lambda and mark it as the dev version.

{ 
  ....
  "scripts": {
     "deploy": "claudia create --version dev --region us-east-1 --api-module api"
  }
}

Anyone can now execute the correct Claudia command just by using:

npm run deploy

You can add more scripts easily. For example, add a step that promotes the latest deployed copy to the production version:

{ 
  ....
  "scripts": {
     "deploy": "claudia create --version dev --region us-east-1 --api-module api",
     "release": "claudia set-version --version production"
  }
}

Now the rest of the team does not need to remember exactly which version is used for what, they can just run the release script to deploy to production.

npm run release

Automating scripts in this way also allows you to set up Claudia as part of your deployment pipeline and automatically use the right configuration easily.

Creating a menu system

The ntl module is a nice way to create a console menu system, so people don’t even need to look up the available scripts in package.json. Install it as a development dependency:

npm install ntl -D

Then, just add a script called start that calls ntl to your project package.json:

{ 
  ....
  "scripts": {
     "deploy": "claudia create --version dev --region us-east-1 --api-module api",
     "release": "claudia set-version --version production",
     "start": "ntl"
  }
}

Now, the only thing people need to remember is to run:

npm start

NPM will present a nice menu for the available deployment options.

More information

For an example of NPM scripts in action, check out the Simple Bot Example Project. That project runs with ntl, so after installing, just use npm start to see the available deployment options.

NPM reserves some package names, such as install, postinstall, test and so on, and it’s best to avoid using those names, otherwise you might end up calling the script unexpectedly. (In particular, avoid using the name publish unless you really know what you’re doing). For a full reference on NPM scripts, check out the main NPM Web site.

Did you like this tutorial? Get notified when we publish the next one.

Once a month, high value mailing list, no ads or spam. (Check out the past issues)