Description
Use case
Note
This issue was opened as a result of this exchange on our Discord Server.
Currently when retrieving parameter values from AWS SSM Parameter Store, the Parameter utility has somewhat generic return types.
For example, when calling the getParameter
function the current return type is string, Record<string, unknown>, undefined
. These types were chosen because they map to the following cases:
string
applies in most cases since SSM supports string values onlyRecord<string, unknown>
applies whenever atransform: 'json'
is applied - in this case Parameters parses the value and returns anobject
undefined
is returned whenever a parameter is not found
Given that the utility knows both the types returned by the API and the transformation to be applied, there's an opportunity to improve the return types by applying some heuristics.
Solution/User Experience
With improved return types, the getParameter
(as well class-based correspondent and potentially the getParameters
), users should be able to obtain stronger typing:
// When we pass transform: 'json', the result will be a Record<string, unknown> because we parse the API result to an object
const objectParam: Record<string, unknown> | undefined = await getParameter('my/param', { transform: 'json' });
// When we pass an object that has no transform, then the result will be a string as we return it straight from the API
const param: string | undefined = await getParameter('my/param', { decrypt: true });
// When we don't pass any options object (so also no transform), then the result should be a string as well
const param1: string | undefined = await getParameter('my/param');
Additionally, you can check this TS Playground.
Alternative solutions
N/A
Acknowledgment
- This feature request meets Lambda Powertools Tenets
- Should this be considered in other Lambda Powertools languages? i.e. Python, Java, and .NET
Future readers
Please react with 👍 and your use case to help us understand customer demand.