Add support for dynamically defined resource names #46
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Problem
Sometimes you want to dynamically define resources and environment variables in your serverless.yml file (i.e. using
Fn::Join
orFn::Transform
). This may get parsed as a python dict instead of a string, which breaks the current logic of this package (TypeError: str expected, not dict
).Proposed Solution
When parsing the serverless.yml file, transform certain properties (like the resource name) from a dict to a string. My solution simply strips invalid characters from the string, so you'd get a resource name like
FnJoin-my-microservicetable
. In my opinion it's not all that important what the transformed string becomes, since you'll want to pass that in as an environment variable anyway if your code needs to know it (see the unit tests I added for an example).Disclaimer
I realize this could be a bit of a rabbit hole... there are all kinds of ways to define things in serverless/cloudformation/yaml, and those things aren't necessarily just the resource name (which is the only thing I've added here). That said, I don't think this hurts anything, and I'd rather the package supports some of these use cases than none at all