Typing environment variables

[pfried]

As you have this nice fromEnv Helper:

asset-tracker-cloud-aws-js/util/fromEnv.ts

Line 1 in e160d89

export const fromEnv =

I thought you may like the idea of typing environment variables as well (following the snake uppercase convention for env params)

export type CamelToSnakeCase<S extends string> = S extends `${infer T}${infer U}`
  ? `${T extends Capitalize<T> ? "_" : ""}${Lowercase<T>}${CamelToSnakeCase<U>}`
  : S;

export type EnvParameters<Type extends Record<string, string>> = Record<
  `${Uppercase<CamelToSnakeCase<Extract<keyof Type, string>>>}`,
  string
>;

Example:

export type WebhookEnvironmentVariables = {
  webhookSecret: string;
  eventQueueName: string;
};

const envParams: EnvParameters<WebhookEnvironmentVariables>

will result in a type

{
   WEBHOOK_SECRET: string;
   EVENT_QUEUE_NAME: string;
}

[coderbyheart]

I am not clear on what problem this addresses. Can you explain what's boy working for you?

Note that we have a standalone version of this function in https://github.com/NordicSemiconductor/from-env-js

[pfried]

This is only a possible improvement, when passing environment variables like here there is no type safety, you can easily forget or misspell a variable which will cause an exception by the fromEnv function.

If you specify a type within your lambda (of expected environment variables) say:

export type LambdaEnviromentVariables = {
  queueUrl: string;
};

Note: Typing the environement variables also allows narrowing the returned type in fromEnv<T>

You could use the derived type from above to specify the expected environment variables in a consistent and typesafe way and still keep the snake-upper-case convention for env variables:

const environmentVariables: EnvParameters<LambdaEnviromentVariables> = {
  QUEUE_URL: queue.url
}

[coderbyheart]

Ah, yes, I get it. I would solve it a bit differently:

• the lambda function should export a type that defines the expected environment variables
• this is imported by the CDK file which defines the lambda resource

This way it's the lambda who "owns" the variable definition, not the CDK, and if the environment variables change, they are changed in the lambda source (where they are needed), so they cannot be forgotten in the CDK definition of the resource.

export type WebhookEnvironmentVariables = {
  webhookSecret: string;
  eventQueueName: string;
};

const envParams: EnvParameters<WebhookEnvironmentVariables>

I am not a fan of this, because I don't want to force the variable name is forced based on the name in the environment. I often use shorter aliases instead of the full converted name.

[pfried]

This way it's the lambda who "owns" the variable definition, not the CDK, and if the environment variables change, they are changed in the lambda source (where they are needed), so they cannot be forgotten in the CDK definition of the resource.

Yeah that is totally what I meant with

If you specify a type within your lambda (of expected environment variables) say

I am not a fan of this, because I don't want to force the variable name is forced based on the name in the environment. I often use shorter aliases instead of the full converted name.

Feel free to close the issue then, I use it in my application and found it helpful when refactoring since you cannot really forget or misspell a variable. It also helps keeping things consistent.