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 a transform: 'json' is applied - in this case Parameters parses the value and returns an objectundefined 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
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
Use case
Currently when retrieving parameter values from AWS SSM Parameter Store, the Parameter utility has somewhat generic return types.
For example, when calling the
getParameterfunction the current return type isstring, Record<string, unknown>, undefined. These types were chosen because they map to the following cases:stringapplies 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 anobjectundefinedis returned whenever a parameter is not foundGiven 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 thegetParameters), users should be able to obtain stronger typing:Additionally, you can check this TS Playground.
Alternative solutions
Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.