Sign inDemoInstall


Package Overview
File Explorer

Advanced tools

Install Socket

Detect and block malicious and high-risk dependencies



TypeScript declarations and helpers for writing CloudFormation templates in TS or JS.

Version published
Install size
28.1 MB




  • Update and re-generate from newer version of AWS spec. Fixes #6
  • Upgrade generator dependencies.
  • Fix support for TypeScript 3.0. Fixes #5
  • Fix confusing build script failure. Fixes #3 and #4



TypeScript declarations for CloudFormation (WIP)

TypeScript declarations for writing CloudFormation stack templates, automatically generated from Amazon's specification files.

Subject to change while I tweak things and figure out a workflow that I like; still a work-in-progress.

Write your CloudFormation stack template in JavaScript or TypeScript with full IntelliSense from these declarations. Then JSON.stringify() the result to a .json file.


Import this module and it'll give you all the helpers and interfaces.

For example:

import {AWS, Template} from 'cloudformation-declarations';
const template: Template = {
    Resources: {
        loadBalancer: AWS.ElasticLoadBalancing.LoadBalancer({
            Properties: {
                Listeners: /*...*/

Helper functions

When declaring resources, you can omit the "Type" property and wrap it in the corresponding helper function. This will give you better Intellisense because it will be limited to properties for that specific Resource type.

    Properties: {
        Listeners: /*...*/
// ... is identical to ...
    Type: 'AWS::ElasticLoadBalancing::LoadBalancer',
    Properties: {
        Listeners: /*...*/

Cloudformation Functions

To use a CloudFormation function, you must skip the Fn:: syntax and call the corresponding factory function.

Join(["a", Ref("foo")])
// instead of
{"Fn::Join: ["a", {"Ref": "foo"}]}

Why are factory functions necessary?

To facilitate readable code-completion popups, we employ a trick for CloudFormation functions. In reality a Cloudformation Ref is a JSON object:

type Ref = {"Ref": StringValue}

...where StringValue is either a string literal or any other CloudFormation function that can return a string, or some deeply nested combination of functions. TypeScript is capable of modeling these possibilities, but it makes the types very complex, which makes tooling much less usable.

Endless union types

Instead, we expose a factory function for each CloudFormation function. Each factory generates the correct JSON structure at runtime, but in TypeScript the return type is the value that will be returned by the CloudFormation function.

TS vs runtime types

As far as TypeScript is concerned, Sub() returns a string. We know better; it is actually creating an object, but that object can be used everywhere that CloudFormation expects a string. We are lying to the type system, but in my experience this is the most pragmatic, productive solution.

Actually<> is a "brand" that exposes the runtime type. This is for advanced situations; you should usually ignore it.

Now our JSDoc popups are much easier to read:

Readable types

To rebuild

(optional) Download up-to-date resource specifications from Amazon.

Or a direct link to the .json file:

Then run the generator script (You'll need node, NPM, and PowerShell core installed, and do an npm install first)

npm run generate



Last updated on 31 Aug 2018

Did you know?

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.


Related posts

SocketSocket SOC 2 Logo


  • Package Alerts
  • Integrations
  • Docs
  • Pricing
  • FAQ
  • Roadmap

Stay in touch

Get open source security insights delivered straight into your inbox.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc