Support for CloudFormation inside serverless.yml

[Birowsky]

The Serverless Framework supports pretty much drop-in CloudFormation code:

https://serverless.com/framework/docs/providers/aws/guide/resources/

It'd be really nice if you could add support for serverless.yml files.

In short, anything within

resources:
  Resources:

is CloudFormation.

[sweepy84]

+1 Really need serverless types in there.

[shalupov]

That's well, a different language to support. Not planned by me at this point, but contributions are welcome

[henhal]

Came here to suggest this and found this.

A different language is perhaps exaggerating a bit. All that's needed is to enable the plugin for everything under resources: in files called serverless.yml.

[henhal]

@shalupov Any chance you might consider this? This is not about supporting a new language, only about how the current file is recognized as containing CloudFormation code.

I have no prior experience from writing IDEA plugins but I tried to look at how this detection works without much success. I understand file type associations, but if you open a .yaml file, the plugin seems to be activated only as soon as the first line starts with AWSTemplateFormatVersion:. How is this accomplished? How do you add logic to activate a plugin based on the content of a file, not the file type?

As @Birowsky mentioned, what's needed for the cloud formation plugin to recognize also inline CF code inside serverless files is to also accept files called serverless.yml containing the lines:

resources:
  Resources:
    <CF code>

If needed, one could of course require some other magic marker such as the AWSTemplateFormatVersion line being present just before Resources: (if the SLS framework accepts that, otherwise perhaps as a comment #AWSTemplateFormatVersion?):

resources:
  # AWSTemplateFormatVersion: '2012-09-01'
  # Treat everything from this level of indentation as a CF document
  Resources:
    <CF code>

There can be only one CF block in a serverless file, if that helps.

This would be extremely useful as it's painful to write CF blocks without any code-completion or other assistance. Granted, when using SLS, it's possible to extract CF to separate files and include them, but you then lose some of the superpowers of SLS, i.e., being able to use SLS variables inside CF blocks etc. And even if modularization and keeping many smaller files is often a good choice, in this case I think it tends to make my SLS files more messy.

If you would reconsider looking at this it would be so awesome, or perhaps give some pointers on where to start with a PR that adds support for detecting that a subset of a file is a CF block.

Alternatively, would it be possible to create a separate serverless plugin that handles the actual detection of an inline CF block and then invokes your plugin as a dependency, with the detected subset of the page as the input to it?

Thanks

[sgarner]

Came here to ask for this too. Would be a nice feature if the CF language support in this plugin could be injectable?

For now I'm just splitting CF templates out of the main serverless config to a separate file which then looks like a regular CF template and can be associated with this CF plugin:

# serverless.yml
service: foo
functions:
  ...
resources: ${file(resources.yml)}

# resources.yml
Resources:
  FooResource:
    Type: AWS::Foo::Bar
    Properties:
      Name: ${self:custom.name} # SLS variable
    ...
Outputs:
  Foo:
    Value: !Ref FooResource
    Description: ...

Granted, when using SLS, it's possible to extract CF to separate files and include them, but you then lose some of the superpowers of SLS, i.e., being able to use SLS variables inside CF blocks etc.

SLS variables still work as normal inside the included file so this isn't a problem.

[henhal]

@sgarner Thanks for your input! I'll give that a new try, I recall having some issues with the extracted file approach when I wrote the above, but if it works it might be an acceptable solution.