Add common production environment key/value parsing example

[bbangert]

I'm submitting a...

• Regression
• Bug report
• Feature request
• Documentation issue or request
• Support request

Current behavior

Environment keys aren't properly cased or camel-cased as is typical when writing the code.

Expected behavior

It should be documented how to perform common key transforms to coerce and transform the key and value as needed for loading an app in dev mode using a yaml file and/or in production using environment variables.

Minimal reproduction of the problem with instructions

Use multiple loaders per https://github.com/Nikaple/nest-typed-config#using-multiple-loaders

Note that if one has a config like:

export class DatabaseConfig {
  @IsNumber()
  public readonly port!: number;

  @IsString()
  public readonly userName: string;
}

Passing the right data in via a config file works easily, but getting the dotenv loader to properly deal with environment variables is not as well documented.

What is the motivation / use case for changing the behavior?

The easiest fix in the documentation is to note in a single spot how to handle what I believe is a relatively common pattern of local config files vs. production environment variable usage. Taking the above example, one needs to make a few tweaks to make that schema work for environment variables like so:

export class DatabaseConfig {
  @IsNumber()
  @Type(() => Number)
  public readonly port!: number;

  @IsString()
  public readonly userName: string;
}

This is documented in the README under variable substitution, but I missed it the first few times trying to find the common handling for environment variables. The section here documenting transforming the variable manually also lends itself to confusing the ideal path:
https://github.com/Nikaple/nest-typed-config#transforming-the-raw-configuration

The last bit missing above is how to get an environment variable into the key format of userName as shown above. I used a key transform like this to solve that generically in a way that'd work for all keys when nesting:

    TypedConfigModule.forRoot({
      schema: RootConfig,
      load: [
        fileLoader(),
        dotenvLoader({
          separator: '__',
          keyTransformer: (key) =>
            key
              .toLowerCase()
              .replace(/(?<!_)_([a-z])/g, (_, p1) => p1.toUpperCase()),
        }),
      ],
    }),

This way DATABASE__USER_NAME=testuser is properly tranlated to the database config of userName.

I think having an example of how to handle the key transform for common camel-cased property names along with the recommendation of using the @Type based value transform would be beneficial to many.

[Nikaple]

The main purpose of the transforming section is to illustrate the usage of normalize method. @Type(() => Number) is truly better than normalize for that part. Would you like to raise a PR by adding a section for common production environment key/value parsing example ?