Share common serverless configuration via nested serverless.yml files

Use case description

A common serverless project structure is to have one repo with many individual services, each service in its own subfolder having its own serverless.yml. There can often be much of the configuration in the serverless.yml files that is common, leading to code duplication.

If we could define multiple “layers” of serverless.yml files, and have them merged together, entire subfolders of services could share common configuration and only override the parts that they need.

Some documentation exists suggesting to use syntax such as `${file(…/…/serverless.common.yml):fooBar} to refer to variables in a common serverless.yml. While this works, it becomes very tedious to manage and if you add a new common configuration you have to make sure to add a reference to it in every child service.

There is also a plugin serverless-plugin-parent which works better, but has the following limitations

• It will only merge in 1 found parent serverless.yml file
• Due to the fact that plugins are loaded AFTER the initial load and validation of the serverless.yml, many properties in the yml file cannot be shared (such as the provider) because the validation will fail if they are missing before the plugin even loads.

Proposed solution

I propose to support a project heirarchy where, upon loading of the serverless.yml file, the directory tree is walked upward, finding each parent folder’s serverless.yml and merging them in (with the items in each child node taking precedence). This would support projects with a structure like

/
     serverless.yml #top level, shared configuration for entire repo
     resources/
          serverless.yml  #shared configuration for all resources
          resourceFoo/
                 serverless.yml #specific configuration for Foo resource
     services/
          serverless.yml #shared configuration for all services
          serviceFoo/
                 serverless.yml #specific configuration for Foo service
           serviceBar/
                 serverless.yml #specific configuration for Bar service

It would be nice if a plugin could handle this but as I mentioned above, since the loading of serverless.yml and subsequent validation of it is before plugins are loaded, they can’t fully do this. Additionally, the use of plugins is specified in the serverless.yml file itself, so specifying of plugins would have to be repeated in each serverless.yml file.

Therefore, I think this should be a feature of the main serverless framework. To support backwards compatibility, it should probably be driven by a configuration parameter in the child serverless.yml file. Perhaps like

service:
   name: foo
   nestedService: true  #open to naming of this

I have a few ideas on where and how this could be implemented in the codebase and I am willing to contribute a PR.

[PatrykMilewski]

@kyle-hiller-nh @drock Consider using this plugin: https://github.com/KrysKruk/serverless-import-config-plugin

It also has some other cool features.

[medikoo]

i.e. a tree structure of serverless files more than one level deep. Is this an intentional limitation or a bug?

If it doesn’t work, it’s a bug (please create a bug report for this). Still variables resolver is scheduled for a complete rewrite that should tackle all known bugs (follow https://github.com/serverless/serverless/issues/7207 and https://github.com/serverless/serverless/issues/8364)