V0.4.0

V0.4.0

There are no breaking changes in this release for project owners. We are committed to not making further breaking changes for several months. Enjoy :)

Updates

Event Support

We're now supporting 4 types of event sources:

• Streams (DynamoDB & Kinesis)
• S3
• SNS
• Schedule

You can configure your event sources in the events property of your s-function.json. The events property is an array of event objects (each function can have multiple events, just like endpoints), and each event object has a name, type and config properties. You can see an example of each supported event source in this test function. You can deploy your configured events in the s-function.json with the new sls event deploy action just like deploying Endpoints.

A likely pattern will be to have one Component for your REST API and another Component for your Events:

project
   api
   events

More information on event support is in the Documentation.

Removal Of Modules Concept

There is no longer any concept of Modules within the Framework. s-modules.json is something we will no longer use. This is for the sake of simplicity.

Instead, you can put functions in the root of your Component, or 1-2 subfolders within a Component. For example:

project/component/function
project/component/subfolder/function
project/component/subfolder/subfolder2/function

You are able to have duplicate function names, however we believe it is a best practice to ensure you have unique names across all of your functions.

If you have s-modules.json in your project, we will continue to support those, but we advise you to change them into s-resources-cf.json files. An explanation on how to do that is in the next note.

Changing Handling Of Resources

Inserting CloudFormation syntax into s-project.json was getting too crowded. We will still support this, but we encourage you to create a s-resources-cf.json file in the root of your project instead, and copy everything into that. Project Templates and Variables can still be used in this file and it is NOT meant to upload directly to AWS CloudFormation.

Since we got rid of s-modules.json and those also used to contain CloudFormation syntax, we now allow you to put more s-resources-cf.json files in the root of your Components and the root of your Component subfolders (1 level deep). This allows you to keep your resources near the application logic that uses it. Please note the s-resources-cf.json that is nested in your Project assets must use different root propeties. (Full details on that are available here)[http://docs.serverless.com/v0.4.0/docs/resources]

Custom Function Names

Every s-function.json file can now have a customName property. This will be the name of your deployed Lambda function on AWS. In this property, you can use Project Variables:

“customName”: “${project}-${stage}-${name}”

You can even use Project Templates AND Variables to specify a function name template, like this:

Put a "functionName": "${project}-${stage}-${name}" key in s-templates.json in the root of your project. ${name} is a reserved Project Variable and is always populated with the name property in the current configuration file. Then in s-function.json, put this: "customName": "$${functionName}".

Custom Lambda Roles

You can now add custom IAM Roles to your Lambda functions via the customRole property in s-function.json. Make sure you put the ARN for the Role in here.

Function Run Local & Deployed Functions

If you provide a stage and region options to sls function run, the command will invoke your deployed function rather than running it locally.

Function Logs w/ Optional Tailing

sls function logs fetches lambda function logs from CloudWatch. You can also use the tailling option to continuously stream logs in the CLI. (Full details are available here)[http://docs.serverless.com/v0.4.0/docs/function-logs]

DashDeploy Improvements

Dash Deploy has lots of new hotkeys thatnks to @jordanmack

Update Dependencies

Our dependencies have been updated to address security concerns

Note To Plugin Developers:

• If you are using the ServerlessModule class in your plugin, you will need to remove that code.
• ServerlessComponent, ServerlessFunction, ServerlessEndpoint and ServerlessEvent class constructor now rely completely on the provided sPath option rather than the component, function, endpoint config options combined. We believe this is much simpler, and we're trying to make the sPath the standard convention for referencing assets in the Serverless Framework.

V0.3.0

V0.3.0

There are no breaking changes in this release for project owners. We are committed to not making further breaking changes for several months. Enjoy :)

Updates

Project Remove

Removes all stages, regions and their resources

Stage Remove

Removes a stage, its regions and their resources

Region Remove

Removes a region within a stage and its resources

V0.2.1

There are no breaking changes in this release. We are committed to not making further breaking changes for several months. Enjoy :)

Fixes

Python Support

Included in this branch are some essential fixes for Python support. Thanks goes out to @ryansb for continuing the great work here.

V0.2.0

V0.2.0

There are no breaking changes in this release for project owners. We are committed to not making further breaking changes for several months. Enjoy :)

Note To Plugin Developers: This version changes the names of two Actions:

• CodePackageLambdaNodeJs -> CodePackageLambda
• CodeDeployLambdaNodeJs -> CodeDeployLambda.
  Those operations will handle ALL Lambda runtimes. This change may affect some plugins, but will not affect any Serverless Projects. The Serverless Optimizer Plugin is affected by this change, but has already been updated to support Serverless Framework v0.2.0. If your project uses the Optimizer plugin, please update it to work with this release of Serverless.

Updates

Python Support

Long-awaited Python support is here, thanks to the uber-talented @ryansb of Serverless Code. We are updating our documentation with Python usage information. Please test it out and let us know what you think. @ryansb is an authority on Serverless Architectures. Check out Serverless Code if you haven't already.

Dash Summary

A new command serverless dash summary shows a summary of your project (e.g., stages, regions, components and more!).

Function Run Improvements

You can now specify a Stage and Region in serverless function run and Serverless will fetch your ENV vars from your Project Bucket and use those in your local function.

v0.1.5

V0.1.5

Fixes

Bring back _init

Brought back the _init method to ensure backward compatibility. Though we'd like to encourage using only init() in the future and not _init()

v0.1.4

V0.1.4

Updates

Templates

You can now add s-templates.json files to the root of your Project, Components, Modules and Functions. Even better, you can inherit templates from parent level template files and extend them in sub-template files. For example:

// project/s-templates.json
{
  "apiRequestTemplate": {
    "application/json": {
      "httpMethod": "$context.httpMethod"
    }
  }
}

// project/component/module/functions-template.json
{
  "apiRequestTemplate": {
    "application/json": {
      "pathId": "$input.params('id')"
    }
  }
}

// This will populate the function endpoint's request template with the merged template:
{
  "apiRequestTemplate": {
    "application/json": {
      "httpMethod": "$context.httpMethod",
      "pathId": "$input.params('id')"
    }
  }
}

You can use templates in an s-.json files and they will inherit/extend themselves intelligently. The Serverless-Starter project has been updated to show examples of useful template inheritance.

More Class Methods

Many classes now have additional methods which you can call to get their parent assets. For example, ServerlessFunction has:

.getModule()
.getComponent()
.getProject()

Bug Fixes

Template Inheritance Bug

In v0.1.3 templates do not inherit subjectively by the assets that were calling them.

v0.1.3

No breaking changes. We are committed to not introducing any further breaking changes for several months.

Updates

Templates

You can now specify templates in your project root folder by creating files that start with s-template.... For example, you can have project/s-templates-cloudFormation.json or project/s-templates-apiGateway.json. You can still have templates in the root of your module folders. However, this syntax is no longer supported for module-level templates $${moduleName.template}. Instead, you specify both Project and Module templates like this: $${template}. If a template key is duplicated in a Project template and a Module template, the module template will not replace, but extend the project level template, increasing reusability and customization. The documentation on this has been updated on our website.

ServerlessState

Added a setAsset() method which allows you to automagically pass in an instance of a Project, Component, Module, Function or Endpoint and it will set it in the right location of the project instance that is within the state instance. /cc @ryansb @joostfarla

DashDeploy

You can now use this in your project's root folder. It shows different content depending on which folder you are in.

StageCreate, RegionCreate

Automatically deploy resources on creation (like we used to).

Region ENV Variable

A SERVERLESS_REGION variable is now auto-created whenever you create a new Stage/Region

Bug Fixes

• Improved readability for people using terminals with white backgrounds
• Runtime properties have been removed from s-function.json and s-module.json

Other Notes

Serverless-Starter

Serverless Projects are now shareable and this is the first. Serverless-Starter is a simple boilerplate project that showcase a couple different ways you can organize your REST API. It's also preloaded with the Optimizer plugin and other useful things like templates.

Serverless-Optimizer-Plugin

The babel support has been finished. You can now use the serverless-optimizer-plugin to bring ES6 to your Lambda functions via Babel!

v0.1.2

No breaking changes. We are committed to not introducing any further breaking changes for several months.

• IMPORTANT: Lambda Logging Bug Fix: If you created a project with V0.1.0 or V0.1.1, a typo prevents your Lambda function from having permission to write to CloudWatch logs. This can be fixed by following the instructions by @lorenzos in #495. Make sure you delete your project's CloudFormation stack, then run serverless resources deploy to recreate it with the new IAM Policy. Thanks @lorenzos!
• New Project Install Command: In v0.1 Serverless Projects are now shareable. The only thing that was missing was a command to install them. This is the first pass at this command and it's still in testing. Please test it out if you get a chance w/ the new Serverless Starter Project. All you have to do is run serverless project install serverless-starter Let us know how it goes!
• New Get Methods: New get methods have been added to our classes to get their parent asset. Thanks @joostfarla!
• Dash Deploy: You can now use serverless dash deploy in your components. If you use it in a component, it will show all functions/endpoints in that component. If you use it in a module, it will show all functions/endpoints in that module.

v0.1.1

No breaking changes. Minor bug fixes.

V0.1.0

This is a major release and represents the finalization of our architecture. For months, we tested every architectural variation. The architecture in v0.1. represents the best possible approach for building AWS Lambda powered applications.

In this release there are several breaking changes. We apologize for this and we sincerely believe these are the last breaking changes. Fortunately, we make these changes to offer you a substantially better workflow, and the improvements in v0.1 will save you a lot of time in the long run.

To transition, we recommend creating a new project with Serverless v0.1.0 and moving your project assets to the new project. Any breaking changes listed below include notes on how to move your assets over to the new project:

• Breaking Change - Single Project Bucket: The framework now creates a single bucket on sls project create to hold all project data for all regions and stages, instead of creating a multiple buckets for each region your project uses. This has been a request for a long time and we've finally made it happen. The downside is existing projects will have to aggregate their regional buckets to the new single Project Bucket. By creating a new Serverless project, you will have the correct bucket naming convention -- serverless.<region>.<domain> -- but make sure you copy assets over to the new Bucket Key Structure, which is:

serverless/<projectName>/<stage>/lambdas // lambda back-ups
serverless/<projectName>/<stage>/<region>/<envVars> // ENV vars
serverless/<projectName>/<stage>/<region>/<resources> // CF Resources

• Project Variables: To reduce configuration settings across your project we now have Project Variables. You can use a Project Variable in any s-project.json, s-component.json, s-module.json and s-function.json file via this syntax: ${variable} Project Variables can be different for stages and their regions, which make them exceptionally powerful. In general, we recommend keeping all of your AWS account specific data in Project Variables.
• Breaking Change - _meta folder: This is a new folder in the root of your project which holds your Project Variables as well as copies of entire CloudFormation Templates that are produced as a result of aggregating all of the CloudFormation properties across your s-project.json and s-modules.json. The Serverless Framework keeps your project stages and regions data in here as well, in the form of folders. In each folder are s-variable.json files for storing stage and region specific Project Variables. By .gitignoring your _meta folder, you can share your project publicly!
• Breaking Change - Components: There is a new tier of organization in Serverless projects to help dependency management and allow for multiple runtimes within a single project, these are called Components. Components designate a runtime (e.g., node.js) and contain a single list of dependencies that is shared across multiple modules and functions (e.g., a single package.json). This allows your modules and functions to all use one set of dependencies, which greatly reduces dependency management and maintenance. Components sit between your project and groups of modules. You can think of Components as microservices. A common pattern is to have 1 component containing modules and functions for a REST API, and another component for modules and functions that respond to events on your AWS account. This could look like this:

project/restAPI-component-nodejs/modules/functions
project/eventHandlers-component-python/modules/functions // Python support is almost finished!

• Breaking Change - Plugin Package.json in Project root: Every Serverless project now expects a package.json in the root of your project, which contains plugin dependencies. This was previously located in project/plugins/package.json, but now is at project/package.json. This was a heavily demanded feature and we hope it makes everyone's workflows much better.
• Breaking Change - Resource Management: There is no longer a resources-cf.json file containing your Serverless Project's resources. Instead, you modify resources in the cloudformation properties of s-project.json and s-modules.json. When you run serverless resources deploy, Serverless aggregates CF resources from your modules and project, then prints a s-resources.json file in your _meta/resources and updates CloudFormation based on that file. You can use serverless resources deploy -c to not trigger the CloudFormation update and only print the s-resources.json file.
• Templates: To further reduce configuration settings in s-module.json and s-function.json we now offer reusable templates. Templates can be any data type (e.g., objects). They are defined in s-templates.json located at the root of your modules: project/component1/module1/s-templates.json. To use a template that is located within a module, use similar syntax to our new Project Variables: $${moduleName.template}. By including the moduleName you can use templates located in other modules. We've almost completed templates at the project level project/s-templates.json which you will specify without the module name, like $${templateName}, but we didn't quite finish it before releasing. If anyone wants to help finish this feature, that would be greatly appreciated :)
• Stage Create & Region Create: When these are created, your CloudFormation resources are no longer deployed by default. You must run serverless resources deploy for those new stages/regions.
• Dash Deploy Must Be Used Within Modules: The Serverless CLI Deployment Dashboard does not work well with long lists of Lambda functions, so you currently can only run it from within a module folder.
• Temporary Removal Of Module Install: We've temporarily removed the module install command so that it will work with our new shareable module design. This will be back shortly.
• Breaking Change - Deployed Function Names Now Include Component Name: To avoid conflicts across deployed lambda functions in multiple project components, deployed lambda names now include the component which they reside within, in your project.
• Breaking Change For Plugins - Introducing Serverless Classes: To provide a better experience for plugin developers, we have stopped attaching large objects to the evt objects that are passed to every Action and Hook. Instead, we now pass only Serverless Paths to identify modules/functions/endpoints the Action should work with. Most importantly, we now have great new classes for Plugin Developers to use when making plugins. We have classes for Serverless Project, Component, Module, Function, Endpoint and more! Each class is full of useful methods which Plugin Developers can use to build faster. Even better, there is a new Serverless State class. This is instantiated each time an Action is run via the CLI or when calling serverless.init() programatically. This State class contains the most methods for Plugin development. These new Classes and their methods represent a stabler API for Plugin developers to rely on, and they are super powerful. Please read more about them in our documentation.