ConfigModule Basics — Series 2

Preview — 3 of 10 questions

Why is forRoot() called here rather than in each feature module?

javascript

@Module({
  imports: [ConfigModule.forRoot({ isGlobal: true }), CatsModule, OrdersModule],
})
export class AppModule {}

AforRoot() sets up the configuration once for the whole application — loading and parsing the environment a single time — so it belongs in the root module; feature modules either rely on isGlobal or import ConfigModule without re-initialising it

BIt must be called in every module that injects ConfigService

CIt may be called anywhere, but only the last call takes effect

DCalling it in a feature module is required for ConfigModule.forFeature() to work

Why this split?

javascript

.gitignore:
  .env
  .env.local

committed:
  .env.example

ABecause .env files are too large to store efficiently in git

BBecause the ConfigModule refuses to read a file that is tracked by git

CBecause .env holds real values, including secrets, which must never enter the repository's history — while .env.example documents the keys an environment needs, with placeholder values, so a new developer knows what to provide

DBecause git normalises line endings, which corrupts environment files

What is wrong with the second line?

javascript

const port = this.config.get('PORT');        // '3000'
if (this.config.get('FEATURE_X')) { /* ... */ }   // FEATURE_X=false

ANothing; the ConfigService converts 'false' to a boolean

Bget() returns undefined for boolean-looking values

CBoolean flags must be named with an IS_ prefix to be recognised

DEvery environment variable arrives as a string, so 'false' is a non-empty string and therefore truthy — the branch runs even though the flag is off; the value needs explicit parsing, ideally once in a typed configuration factory

Answer all 10 questions (7 more), see explanations for every answer, and track your score.