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.

Minor Fixes

• Fix FunctionName conventions to not include ModuleName
• Fix bug that created undefined in event.json on FuctionCreate.
• Fixes and improvements for the utlities cliSelectRegion() function.
• Display information about endpoints that failed to deploy
• Better error messages in FunctionRun

Minor Fixes

Minor Fixes

• Fixes project create folder creation -- Thanks @Nopik
• Fixes the creation of event.json in the FunctionCreate Action so that it properly creates a property in event.json named after the recently created function.

(Minor breaking changes) Dash, Multi-Endpoints, Plugins & More

Note: This release features a few breaking changes. We are stabilizing quickly and we're sorry for these. We believe these will be some of the last. Here is what you must change:

Breaking Changes & How To Fix Them

• s-function.json: The s-function.json format had to be amended slightly to improve handling multiple endpoints per function. The endpoints property used to be an object with the endpoint's path as the key. Now, the endpoints property is an array of endpoint objects, and a path property has been added to each object. Please make this change to all of your s-function.json files.
• resources-cf.json: Since AWS CloudFormation recently added support for grouping and customizing parameter ordering and labeling, we decided to strip the aa prefix on the Parameters in the resources-cf.json. We recommend changing the Parameters in your resources-cf.json and deployed Serverless Project Resources to remove the aa prefixes. From this point on, use the grouping, customizing parameter ordering and labeling to stay organized. See #369 for more information.
• Serverless Plugins: We believe the Plugin system is now very stable after this last minor change. The first parameter to pass into your Plugin is not a path, but the ServerlessPlugin class. Now, you don't have to load it yourself. The second parameter is the path. See #368 for more information. The Serverless Plugin Boilerplate has also been updated to work with this change.

New Features

• Dash is back! The deploy dashboard is back. Run serverless dash deploy to deploy both functions and endpoints in one screen. Since command line interfaces are buggy, make sure your terminal window is as tall as possible if you have a lot of functions and endpoints.
• Many fixes: Multiple endpoints work better, thanks to the breaking change above. We've also fixed the requestParameters issue reported in #366 : We've started making lots of changes to help with Windows use, but we still have some more to make. However, we did fix #365. Please let us know of other compatibility issues :)

Enjoy,
Serverless Team

Delete Mysterious Serverless.json Bug

• A serverless.json file was being mysteriously created in Project folders. This behavior has been removed.
• This release also features some changes for Plugin authors who want to use sym links to build their Plugins.

External Plugin Support Now Available

• In this release, the Framework now loads external plugins if they are located in either a plugins/node_modules or a plugins/custom folder within the root of your project.

Fixed Bugs in EndpointDeploy, FunctionCreate and ModuleCreate

• We fixed the last of the bugs in EndpointDeploy, FunctionCreate and ModuleCreate in this version.

Minor Bug Fixes

Some of the bugs we attempted to fix in this version were not fixed until version 0.0.10. We recommend using that version in place of this one.

Command Line Shortcut Changes, API Gateway Fixes and Action Event Object Cleanup

Some of the bugs we attempted to fix in this version were not fixed until version 0.0.10. We recommend using that version in place of this one.

• In this release we changed the shortcut for the command line from sl to sls or slss. We received several concerns that sl would be a conflict on Linux systems, hence the shortcut change.
• To put the final touches on our Plugin Architecture, we cleaned up the event object across all Actions to have consistent properties and property name formats.
• There was an issue with API Gateway Endpoints that use a Resource in a Path twice (e.g., myapi.com/users/users). This release was an attempt to fix that, but we found further bugs after releasing this release and were unable to fix them until version 0.0.10.
• We also fixed an issue that prevented users from setting their API Keys in the ProjectCreate Action.