Use process.env for PORT

I’m submitting a…

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

Current behavior

Starting a new project includes an anti-pattern concerning the handling of configuration. Specifically, src/main.ts has the app listen on a hardcoded port.

E.g.

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

On its own this is a seemingly small thing, but it elevates the risk of projects neglecting one of the tenants of The Twelve-Factor App:

Store config in the environment

_https://12factor.net/config_

A consumer of the framework would need to be aware of this anti-pattern and discover the documentation recommending how to properly handle configuration with Nest.

Expected behavior

Instead of the app listening to a hardcoded port, use a ConfigService class as suggested in the docs to pull the port from the environment.

Documentation should also link users to the page on configuration techniques.

Minimal reproduction of the problem with instructions

Start a new project with Nest’s CLI (nest new project) and see that src/main.ts has hardcoded port.

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

Two motivations for this feature request:

1. Mitigate risk of applications being built on top of an anti-pattern.
2. Educate developers who are newer to backend development by putting best practices in the critical path of using Nest.

Environment

@nestjs/cli: 5.8.0
@nestjs/common: 5.4.0
@nestjs/core: 5.4.0

[ryakoviv]

export class AppModule {
   static port: string
  constructor(configService: ConfigService) {
    AppModule.port = configService.get('HTTP_PORT')
  }
}

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(AppModule.port || 3000);
}
bootstrap();

[felixhayashi]

Actually, there is a popular npm package (https://github.com/lorenwest/node-config) that allows you to define config files for different “environments” and at runtime it will pick the config matching NODE_ENV. I think this sufficiently abstracts the configuration process and makes it fairly easy to switch environments (see the README examples). As @kamilmysliwiec noted, it is fine that this aspect of the configuration mechanism is not provided as a service since the bootstrap() is out of the DI-scope anyways. Of course, nonetheless, nothing prevents you from wrapping the config mechanism in a service to provide it to other parts of your app later.