feat(parameters): stronger types for SSM getParameter #1387
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.
Description of your changes
As discussed in the linked issue, the return types for the
SSMProvider
part of the Parameters utility are fairly generic and could be improved by applying some heuristics based on the method used and some of the parameters passed. In addition to that, we could also provide a way for users to explicitly set the return type when they know the shape of the values they are retrieving.This PR introduces new types types for the
getParameter()
,getParameters()
, andgetParametersByName()
functions as well as their class-based corespondents (i.e.SSMProvider.get()
, etc.).The new types use generics and modify the return type of the functions/methods based on the arguments passed to them or based on an explicitly set type.
For instance, if users pass
transform: 'json'
, then we can assume that the return type should be an object (Record<K, V>
). Conversely, if no transform or abinary
(base64) transform is applied, the result will always be a string.We can apply a similar logic to both single and multiple values retrieval, with the only difference that in the latter case the return type will always be nested inside an object: i.e.
getParameters('/my/path')
(aka no transform) will always yield an object that has strings as both keys and values (Record<string, string>
):In the case of objects (
transform: 'json'
), I have opted to useunknown
overany
, in an effort to nudge users to not typecast indiscriminately but instead use type guards like:which can help TypeScript to narrow down types, like:
There are however still cases in which users might know more about the values they are retrieving than the compiler does, and for those instances this PR introduces the ability to specify the return type while using any of the SSM methods like so:
In the first example above the
value
constant will have typenumber
, this is because the user has specified a type and so this will take precedence over any type-heuristic we do behind the scenes.Likewise, in the second example, the
objValue
constant will haveRecord<string, Record<string, number>>
, i.e.:Notice that in the second case we are not passing the full
Record<string, xxx>>
but only the inner type. This is because in the case ofgetParameters
we are always returning an object that has keys (of typestring
) that correspond to the name/path of the parameter and as values the actual values. This allows users to specify only the type of the actual value and avoid unnecessary boilerplate.Once merged this PR closes #1386
Related issues, RFCs
Issue number: #1386
Checklist
Breaking change checklist
Is it a breaking change?: NO
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.