Serverless variable syntax and AWS

Is there any chance the serverless variable syntax will be revisited? Having it conflict with AWS’ syntax is going to be a problem forever going forward. Each person who starts doing more advanced things on AWS is going to need to learn how to change it.

Everyone of my YAML files has this…

  # NOTE: by default AWS variables like ${saml:sub} use same format as
  # Serverless variables like ${self:custom.prefix} We use variableSyntax here
  # to change serverless vars to look instead like $<self:custom.prefix>
  variableSyntax: '\$<([ :a-zA-Z0-9._,\\-\\/\\(\\)]+?)>'

@jonsmirl, so does AWS throw an error when it encounters the framework’s vars., or the framework is throwing an error as it cannot find the AWS vars? I am guessing the latter but please confirm.

AWS and severless use the same default syntax for their variables so when serverless processes an AWS variable it gets an error. The syntax conflict is with AWS policy variables.

By the time your YAML get loaded up to AWS all of the serverless syntax is gone.

If you really, really want them to keep using the same variable syntax you could teach serverless about all of the possible AWS variables so that it won’t declare them errors. But that set of variables changes as AWS evolves. Plus I suspect it will be very confusing for users if you do this, some variables will evaluate locally and others would evaluate in the cloud. Much better to simply change the SLS variable syntax to not conflict.

With the current scheme the first time you try and use an AWS policy variable you will get an error from SLS about an undefined variable. You will stare at that error for a while and swear that your syntax is correct – and it is. After a while you will start asking on the forum and searching in Google. Sooner or later you will find something that explains this problem and which recommends changing your SLS variable syntax – like in the first post in this thread. After you change the SLS syntax you will then have to go back through all of your YAML files and edit them to use the alternative syntax.

1 Like