Great question! I totally get the frustration—having to define all validation schemas in the root ConfigModule.forRoot() feels like it breaks the modular design you're going for. Luckily, there are a couple of clean ways to keep validation logic tied to your feature modules while still using partial registration with forFeature().

Option 1: Use registerAs with Per-Feature Schemas (Root-Level Merging) #

This approach keeps your schema definitions in the feature module, then merges them into the root ConfigModule's validation. It's a middle ground between global validation and full feature isolation.

Step 1: Define Feature Config and Schema Together #

In your feature's config file (e.g., database.config.ts):

import { registerAs } from '@nestjs/config';
import * as Joi from 'joi'; // or Zod if you prefer

// Register the feature config under a namespace
export const databaseConfig = registerAs('database', () => ({
  host: process.env.DB_HOST,
  port: parseInt(process.env.DB_PORT, 10),
  username: process.env.DB_USERNAME,
  password: process.env.DB_PASSWORD,
  database: process.env.DB_DATABASE,
}));

// Define the validation schema for this feature
export const databaseSchema = Joi.object({
  DB_HOST: Joi.string().required(),
  DB_PORT: Joi.number().default(5432),
  DB_USERNAME: Joi.string().required(),
  DB_PASSWORD: Joi.string().required(),
  DB_DATABASE: Joi.string().required(),
});

Step 2: Merge Schemas in Root ConfigModule #

In your root module (e.g., app.module.ts), import all feature schemas and merge them into the validate option:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { databaseSchema } from './database/config/database.config';
import { DatabaseModule } from './database/database.module';

@Module({
  imports: [
    ConfigModule.forRoot({
      validate: (config) => {
        // Merge all feature schemas into one
        const combinedSchema = Joi.object({
          ...databaseSchema.describe().keys,
          // Add other feature schemas here as your app grows
        });

        const { error, value } = combinedSchema.validate(config, { abortEarly: false });
        if (error) {
          throw new Error(`Config validation failed: ${error.message}`);
        }
        return value;
      },
    }),
    DatabaseModule,
  ],
})
export class AppModule {}

Step 3: Use the Config in Your Feature Module #

In DatabaseModule, still use forFeature() to access the namespace config:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { databaseConfig } from './config/database.config';
import { DatabaseService } from './database.service';

@Module({
  imports: [ConfigModule.forFeature(databaseConfig)],
  providers: [DatabaseService],
  exports: [DatabaseService],
})
export class DatabaseModule {}

Then in DatabaseService:

import { Injectable } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';

@Injectable()
export class DatabaseService {
  constructor(private configService: ConfigService) {
    // Access the namespaced config
    const dbConfig = this.configService.get('database');
    console.log(dbConfig.host);
  }
}

Option 2: Feature-Level Validation with a Custom Config Service #

This is my preferred approach for full isolation—validation happens directly in the feature module, so the root module doesn't need to know about feature-specific schemas at all.

Step 1: Create a Feature-Specific Config Service #

In your feature module, create a service that handles validation and exposes typed config values:

import { Injectable, OnModuleInit } from '@nestjs/common';
import { ConfigService } from '@nestjs/config';
import * as Joi from 'joi';

@Injectable()
export class DatabaseConfigService implements OnModuleInit {
  readonly host: string;
  readonly port: number;
  readonly username: string;
  readonly password: string;
  readonly database: string;

  constructor(private configService: ConfigService) {}

  onModuleInit() {
    // Pull raw env vars
    const rawConfig = {
      DB_HOST: this.configService.get('DB_HOST'),
      DB_PORT: this.configService.get('DB_PORT'),
      DB_USERNAME: this.configService.get('DB_USERNAME'),
      DB_PASSWORD: this.configService.get('DB_PASSWORD'),
      DB_DATABASE: this.configService.get('DB_DATABASE'),
    };

    // Validate the config
    const schema = Joi.object({
      DB_HOST: Joi.string().required(),
      DB_PORT: Joi.number().default(5432),
      DB_USERNAME: Joi.string().required(),
      DB_PASSWORD: Joi.string().required(),
      DB_DATABASE: Joi.string().required(),
    });

    const { error, value } = schema.validate(rawConfig, { abortEarly: false });
    if (error) {
      throw new Error(`Database config validation failed: ${error.message}`);
    }

    // Assign validated values
    this.host = value.DB_HOST;
    this.port = value.DB_PORT;
    this.username = value.DB_USERNAME;
    this.password = value.DB_PASSWORD;
    this.database = value.DB_DATABASE;
  }
}

Step 2: Register the Service in Your Feature Module #

You don't even need forFeature() here unless you still want to use the namespaced config—this service pulls directly from the root ConfigService:

import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
import { DatabaseConfigService } from './database-config.service';
import { DatabaseService } from './database.service';

@Module({
  imports: [ConfigModule], // Just import the base ConfigModule
  providers: [DatabaseConfigService, DatabaseService],
  exports: [DatabaseService],
})
export class DatabaseModule {}

Step 3: Inject the Custom Config Service #

Now in your DatabaseService, inject the typed, validated config directly:

import { Injectable } from '@nestjs/common';
import { DatabaseConfigService } from './database-config.service';

@Injectable()
export class DatabaseService {
  constructor(private dbConfig: DatabaseConfigService) {
    console.log(this.dbConfig.host); // Typed and validated!
  }
}

Why This Works #

• Option 1 keeps validation centralized but organized by feature, which is great if you want all config validation to run on app startup.
• Option 2 fully encapsulates validation within the feature module, which aligns perfectly with modular design principles—each feature owns its own config logic.

Both approaches avoid forcing all validation schemas into forRoot(), so you can maintain clean, modular code while still ensuring your configs are valid.

内容的提问来源于stack exchange，提问作者warreee