Access validated config from custom configuration files

[h4ckthepl4net]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

TLDR;

Inability to access validated and parsed environmental values in custom configuration files. The validated values are stored in the configuration object of ConfigService under a constant key, but are inaccessible in custom configuration files and cannot be injected.

Problem

When utilizing @nestjs/config with Joi validation and multiple custom configuration files, we encounter a significant type preservation issue. After Joi validation and conversion of configuration values (e.g., numbers, booleans), these values are written back to process.env, which exclusively supports string values. Consequently, when accessing these previously validated values from process.env in custom configuration files, developers must redundantly re-parse them from strings to their appropriate types, leading to:

1. Redundant type conversion
2. Potential type inconsistencies
3. Decreased performance
4. Additional boilerplate code

Example of the problem:

// validation schema
const validationSchema = Joi.object({
  PORT: Joi.number().default(3000),
  DEBUG: Joi.boolean().default(false)
});

// custom configuration file
export default registerAs('database', () => ({
  port: parseInt(process.env.PORT, 10), // Redundant parsing
  debug: process.env.DEBUG === 'true', // Redundant parsing
}));

Describe the solution you'd like

Solution

Implement a globally accessible store for parsed and validated configuration values via process.parsedEnv or global.parsedEnv that:

• Maintains type safety through TypeScript declarations
• Remains read-only to prevent runtime modifications
• Is available during module initialization
• Provides proper typing information for IDE support

Example implementation:

// After validation
process.parsedEnv = readonlyValidatedConfig;

Potential drawbacks:

• Slight increase in memory usage
• Maybe need to maintain some additional TypeScript types
• Potential for confusion between process.env and process.parsedEnv

Teachability, documentation, adoption, migration strategy

Usage, Migration, Docs

This enhancement requires minimal documentation updates as it's not a breaking change. A simple addition to the documentation would suffice:

// Previous approach
const port = parseInt(process.env.PORT, 10);

// New approach
const port = process.parsedEnv.PORT; // Automatically typed as number after conversion is done

Migration is straightforward as:

• No breaking changes to existing functionality
• Gradual adoption possible
• Needed TypeScript types will be included for IDE support

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

Motivation and benefits

The primary motivation is to improve developer experience and reduce potential errors in NestJS applications by:

1. Eliminating redundant type parsing and validation
2. Ensuring type consistency throughout the application
3. Reducing boilerplate code in configuration files
4. Improving maintainability by centralizing parsed values
5. Enhancing TypeScript integration and type safety

Key use cases:

• Applications with complex and rapidly changing configuration requirements
• Environments where type safety is crucial
• Development scenarios requiring consistent configuration access across multiple modules