Currently @ is not a valid variable character, so it doesn't get parsed
as one.
When it does get parsed, @ is not considered valid as part of a file path
- we add a blacklist as per https://github.com/serverless/serverless/pull/4528 to
handle this case.
If an override comes back as a variable containing a deep variable (e.g. `''${self:custom.${deep:1}, "fallback"}''`) or really any variable at all, it needs to be made a deep variable and paused for next iteration. Do this generally rather than only in the case of deep variables. See the test case for a circumstance that the prior fix didn't resolve. This more generalized handling improves the fix and solves a remaining issue we found locally.
Use the variable string from which the overwrite parameters were extracted as the replacement target (in the case of deep variable discovery) rather than the context property which represents the entire original value that the replacement is being waited upon. That context property can contain far more content than the overwrite string itself.
This avoids taking a deep value as a valid term within an overwrite
(defaulting) variable statement that will later resolve to undefined
but, as a deep variable string, is valid in immediate evaluation.
Fixes#5027
Use the variable syntax present in the given variable string, extracting it from the given string that may contain embedded custom variables (i.e. `${{self:var.${{self:var.foo}}.bar}}`).
Handle `self:service.[...]` references properly. The prior represents what the user typed into their configuration. In service, we move all this from `service` to `serviceObject`, therefore, by rewriting `self:service.[...]` to `self:serviceObject.[...]` user's will get the result they expect.
Use else if, given exclusivity of conditions
The framework's Service class modifies a user's service, mutating a given `service: { name: 'string' }` to `service: 'string'` but doesn't account for this in the variables system. This is the basis for #4744.
While working this area, I discovered that the Service class also does this to the provider, accepting `provider: 'aws'` and replacing it with `provider: { name: 'aws' }`, causing the natural `${self:provider}` to fail.
Catching either 'self:service.name' or 'self:provider' and replacing them with the mutated reference solves this user confusion.
Fix `print`
The print command is highly linked to the `Variables` and `Service` codebases, keep those in sync and leave reminders about the link. Made these explicit and separately implemented to avoid complexity.
Additionally, the print command re-populates an object with the *very similar* content as the previously pre-populated service (just not augmented as just mentioned). This can lead to cross contamination between the two. As such, all caches must be cleared per unique invocation of service/object/property population.
Add tests for some expected but previously unverified behaviors.
Clean pre-population
The previous implementation worked okay but was unnecessary and would have been a maintenance problem. Instead, just knock out the population of variables depending on those config dependent services and use the standard means of resolution.
Fix cyclic bug (resulting from running print against a self-referencing serverless.yml)
The caching of values could lead to a cyclic object remaining in the caches for variable population. This causes crashes and pain. Solved by the cache cleaning logic.
Simple oversight that deep variables can reference overwrites too. This fix acknowledges this oversight by using the standard logic for using overwrite instead of getValueFromSource in this case.
#4311
see prepopulateService - attempts to pre-populate the region and stage settings necessary for making a request to AWS, rejecting and dependencies thereon it runs into during that process
see the `deep` variable work. this was a knock-on effect of providing pre-population. it actually represents an obscure class of bugs where the recursive population previously in getDeepValue caused the caller not to be in charge of population choices (thus fixing for pre-population) but also caused potential deadlocks resulting from getDeepValue creating circular dependencies.
#4734
see splitByComma - a regex to do the splitting but ignore quoted commas was getting very deep and involved. Instead, identify quoted string boundaries, then identify commas (including white space around them) and take those commas not contained by quotes as the locations for splitting the given string. Trim the string as well (removing leading and trailing white space).
add sophistication to the overwrite syntax, allowing for whitespace and repetitions (for robustness)
add sophistication to the string ref syntax, allowing for use in identifying multiple quoted strings in a variable (i.e. for overwrites)
#NotCreated
fix a bug I created earlier in the branch that caused reporting to be less informative (see renderMatches)
separate PromiseTracker
move this class into its own file for the purpose of increasing testability and offering reuse
minutiae
filter the properties given to populateVariables so as to avoid attempting resolution on non-variables. Efficiency and noise reduction change. Also cleans up the code (e.g. see populateObject and its use)
cleaning of overwrite as a side effect
offer variable cleaning as a idiom
reorder the Variables.js `require`s to be in alphabetical order
Add a "PromiseTracker" to the Variables class. It provides tracking and reporting of pending variable resolutions during service populations.
Decompose populateObject and populateProperty into smaller pieces that are easier to understand.
Additionally, remove the immediate recursive resolution of variables, recursing only at the Object or Property entry point (when changes have been made). This avoids a problem where the resolved value, prior to being replaced in the containing object or value refers to itself and thereby is waiting on its own resolution before it will resolve itself.
Return the given value in warnIfNotFound so that it can chain.
Delete bucket was still using them
Hopefully all :)
Further test fixes.
.... worked too long yesterday
Fixed Variable tests
Remove not used parameters from request() and add options with warning
1. add tests that validate string value defaults in overrides.
2. add test of behavior when a javascript's export does not contain the attribute declared in the variable.
3. add tests of behavior when an SSM parameter is not found and the request to the SSM service fails.
add returns to tests that weren't returning their promises (and were thereby risking false positives.
Increase name consistency
Improve names to be-what-they-are
Reduce cyclomatic complexity
Include overrides population fix
Add variable methods documentation
Add more tests around significant variable patterns/risky cases
Make sure that requests are throttled. Use a queue for the requests.
Added new expected parameter to request() call in variables test
Added request cache tests
Check that request is indeed called 1000 times
Cache promises, not values
Use request cache for AWS variable requests
Use fromCallback instead of "new Promise" anti-pattern.
Added request cache to AWS provider
