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.