![](\"https://avatars1.githubusercontent.com/u/43827489?s=400&u=45ac0ac47d40b6d8f277c96bdf00244c10508aef&v=4\"/)
\n ![\"travis\"/](\"https://travis-ci.org/nestjsx/nestjs-config.svg?branch=master\")
\n ![\"npm\"/](\"https://img.shields.io/npm/v/nestjs-config.svg\")
\n ![\"license\"/](\"https://img.shields.io/github/license/nestjsx/nestjs-config.svg\")
\n ![\"coveralls\"/](\"https://coveralls.io/repos/github/nestjsx/nestjs-config/badge.svg?branch=master\"){kind=icon}
\n ![\"package](\"https://npm.packagequality.com/shield/nestjs-config.svg\")
\n \n
\n
![\"Awesome](\"https://raw.githubusercontent.com/nestjsx/crud/master/img/awesome-nest.svg?sanitize=true\")
\n ![\"Nest](\"https://raw.githubusercontent.com/nestjsx/crud/master/img/nest-powered.svg?sanitize=true\")
\n \n ![\"npm](\"https://img.shields.io/npm/dt/nestjs-config.svg\")
\n \n
Configuration component for NestJs.
\n\n## Features\n\n- Load your configuration files using globs\n- Support for different environment configurations, thanks to [dotenv](https://github.com/motdotla/dotenv)\n- DI your configurations\n- Customisable config tokens\n\n### Installation\n\n**Yarn**\n\n```bash\nyarn add nestjs-config@next\n```\n\n**NPM**\n\n```bash\nnpm install nestjs-config@next --save\n```\n\n### Getting Started\n\nLet's imagine that we have a folder called `src/config` in our project that contains several configuration files.\n\n```bash\n/src\n├── app.module.ts\n├── config\n│ ├── express.ts\n│ ├── graphql.ts\n│ └── grpc.ts\n```\n\nLet's register the config module in `app.module.ts`\n\n```ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.forRootAsync(\n path.resolve(__dirname, 'config', '**/!(*.d).{ts,js}'),\n ),\n ],\n})\nexport class AppModule {}\n```\n\nThat's it!\n\n---\n\n#### Complex Project Structure\n\nNow let's say that your application isn't located in a folder called `src`, but it's located in `src/app`.\n\nWe want to be able to set a different 'root path' to load our configurations from. Be it `src` or `dist`.\n\nImagine a more complex project structure like this:\n\n```\n/\n├── dist/\n├── src/\n│ ├── app/\n│ │ ├── app.module.ts\n│ │ └── bootstrap/\n│ │ │ ├── index.ts\n│ │ │ └── bootstrap.module.ts\n│ ├── migrations/\n│ ├── cli/\n│ ├── config/\n│ │ ├── app.ts\n│ │ └── database.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\nIn this example, config files are located in the `/src/config` folder, because they are shared\nbetween app, migrations and cli scripts.\n\nAlso during typescript compilation all files from `src/` folder will be moved to the `dist/` folder.\n\nMoreover, the `ConfigModule` is imported in the `BootstrapModule`, but not directly in `AppModule`.\n\n```ts\n// app.module.ts\nimport { Module } from '@nestjs/common';\nimport { BootstrapModule } from './bootstrap';\nimport { ConfigService } from 'nestjs-config';\n\nConfigService.rootPath = path.resolve(__dirname, '..');\n\n@Module({\n imports: [BootstrapModule],\n})\nexport class AppModule {}\n```\n\n```typescript\n// bootstrap.module.ts\nimport * as path from 'path';\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\n\n@Module({\n imports: [\n ConfigModule.forRootAsync(path.resolve('config', '**/!(*.d).{ts,js}')),\n ],\n})\nexport class BootstrapModule {}\n```\n\nSetting the `ConfigService.rootPath` before calling `ConfigModule.forRootAsync(...)` will change the default root dir of where your configs are loaded from.\n\nAnother method is to invoke `ConfigModule.resolveRootPath(__dirname)` from any module before loading the config and use glob with a relative path.\n\n```ts\n// bootstrap.module.ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\n\n@Module({\n imports: [\n ConfigModule.resolveRootPath(__dirname).forRootAsync(\n 'config/**/!(*.d).{ts,js}',\n ),\n ],\n})\nexport class BootstrapModule {}\n```\n\nIn both cases we provide the glob of our configuration as first argument, but it is relative to the `src/` folder (or eventually `dist/`).\n\n## DI configs\n\nDependancy Injection for your configs.\n\n```ts\nimport { Config } from 'nestjs-config';\n\nexport default class SomeClass extends Config {\n someProperty: process.env.SOME_ENV;\n}\n```\n\nThis feature was added mainly for use with other forRootAsync modules and to remove the need of injecting the ConfigService everywhere.\n\n```ts\n@Module({\n imports: [\n ConfigModule.forRootAsync(path.resolve('config/**/!(*.d).{ts,js}')),\n TypeOrmModule.forRootAsync({\n injects: [DatabaseConfig],\n useFactory: (config: DatabaseConfig) => config,\n }),\n AmqpModule.forRootAsync({\n injects: [AmqpConfig],\n useFactory: (config: AmqpConfig) => config,\n }),\n ],\n})\nexport class SomeModule {}\n```\n\n## Config Object\n\nBy default config files are now converted into a Config object which is esentailly a stripped version of the ConfigService. The idea is you can pass and amend any structure and keep the `get` method to use lodash.get for patterns and the default value.\n\n```ts\n// config/some.ts\nexport default {\n value: {\n in: {\n pattern: false,\n },\n },\n};\n\n// some.module\n@Module({\n imports: [\n ConfigModule.forRootAsync(path.resolve('config/**/!(*.d).{ts,js}')),\n ],\n providers: [\n {\n useFactory: (config: SomeClass) =>\n new SomeProvider(config.get('some.value.in.pattern', 'default')),\n injects: [SomeClass],\n },\n ],\n})\nexport class SomeModule {}\n```\n\nIt's also possible to extend the Config class from your config file and define your own methods!\n\n```ts\n// config/anything.you.like.ts\nexport default class MyConfig extends Config {\n value: {\n in: {\n pattern: false,\n },\n },\n\n getPattern(): boolean {\n return this.value.in.pattern;\n }\n};\n\n// some.module\n@Module({\n imports: [\n ConfigModule.forRootAsync(path.resolve('config/**/!(*.d).{ts,js}')),\n ],\n providers: [\n {\n useFactory: (config: MyConfig) => new SomeProvider(config.getPattern()),\n injects: [MyConfig],\n },\n ],\n})\nexport class SomeModule {}\n```\n\n## Defined config provider token/name\n\nIt's possible to change the provider token and pattern prefix. By default the file name will be used as like v1. With v2 it's possible to define your `__provide` and `__name` properties on the object like so.\n\n```ts\nexport default {\n __provide: 'my_token',\n __name: 'my_name',\n};\n```\n\nIf you define just `__provide` it will be used for both token and pattern prefix. Defining just `__name` will also be used for both token and pattern prefix. Defining both means `__provide` will be your token and `__name` will be your pattern prefix.\n\n> Custom tokens can be injected using the `@InjectConfig(${__provide})` decorator. \n\n## Multi-modular config usage\n\nIn some cases your structure might take on this shape\n\n```\n/\n├── src/\n│ ├── cats/\n│ │ ├── cats.module.ts\n│ │ └── cats.config.ts\n│ ├── dogs/\n│ │ ├── dogs.module.ts\n│ │ └── dogs.config.ts\n│ ├── app.module.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\nWith the examples above you'd have to call your config like so `ConfigService.get('dogs.config.bark')`. You can use the `__provide` method option to change the token of your configs\n\n```ts\n//config/dogs.config.ts\nexport default {\n __provide: 'dogs',\n bark: 'woof',\n};\n\n//app.module\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.forRootAsync(\n path.resolve(__dirname, '**/!(*.d).config.{ts,js}'),\n ),\n ],\n})\nexport class AppModule {}\n```\n\nNow you can call your config like so `ConfigService.get('dogs.bark')`.\n\n## Production environments\n\nYou might have notice the use of `config/**/!(*.d).{ts,js}` in the glob. When running in production (running in JavaScript after TypeScript compilation) we want to disinclude the TypeScript definition files. The use of `config/**/*.ts` is fine in dev environments but we recommend using this example `config/**/!(*.d).{ts,js}` to avoid issues later on when running in a production environment.\n\n## Environment Configuration\n\nThis package ships with the amazing [dotenv](https://github.com/motdotla/dotenv) package that allows you to create\na `.env` file in your preferred location.\n\nLet's create one, for demo purposes!\n\n```bash\n# .env\nEXPRESS_PORT=3000\n```\n\nNow, in our `src/config/express.ts` configuration file, we can refer to that environment variable\n\n```ts\n// src/config/express.ts\nexport default {\n port: process.env.EXPRESS_PORT || 3000,\n};\n```\n\n> **Note:** By default the package will look for a `.env` file in the path that you have started your server from.\n> If you want to specify another path for your `.env` file, use the second parameter of `forRootAsync`.\n\n### Usage\n\nNow we are ready to inject our `ConfigService` anywhere we'd like.\n\n```ts\nimport { ConfigService } from 'nestjs-config';\n\n@Injectable()\nclass SomeService {\n constructor(private readonly config: ConfigService) {}\n\n isProduction() {\n const env = this.config.get('app.environment');\n\n return env === 'production';\n }\n}\n```\n\nYou may also use the `@InjectConfigService` decorator as following:\n\n```ts\nimport { InjectConfigService } from 'nestjs-config';\n\n@Injectable()\nclass SomeService {\n constructor(@InjectConfigService() private readonly config) {\n this.config = config;\n }\n}\n```\n\n## Custom Helpers\n\nThis feature allows you to create small helper function that computes values from your configurations.\n\nReconsider the `isProduction()` method from above. But in this case, let's define it as a helper:\n\n```ts\n// src/config/express.ts\n\nexport default {\n environment: process.env.EXPRESS_ENVIRONMENT,\n port: process.env.EXPRESS_PORT,\n\n // helpers\n isProduction() {\n return this.get('express.environment') === 'production';\n },\n};\n```\n\nYou can use the helper function as follows:\n\n```ts\n// this.config is the ConfigService!\nthis.config.get('express').isProduction();\n\n// or\nthis.config._isProduction(); // note the underscore prefix.\n```\n\n#### Global Helpers\n\nYou can also attach helpers to the global instance as follow:\n\n```ts\nthis.config.registerHelper('isProduction', () => {\n return this.get('express.environment') === 'production';\n});\n```\n\nAnd then use it like this:\n\n```ts\nthis.config.isProduction(); // note the missing underscore prefix\n```\n\n## Decorators\n\nAs of version 2, decorator support for parameter injection has been removed as they weren't great.\n\n## TypeORM\n\nUsing the `ConfigModule` in combination with [TypeORM](https://github.com/typeorm/typeorm) (e.g. in order to configure TypeORM) requires using the `forRootAsync()` function supplied by the typeorm package for nestjs (`@nestjs/typeorm`)\n\n```ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule, ConfigService } from 'nestjs-config';\nimport { TypeOrmModule } from '@nestjs/typeorm';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.forRootAsync(\n path.resolve(__dirname, 'config', '**', '!(*.d).{ts,js}'),\n ),\n TypeOrmModule.forRootAsync({\n useFactory: (config: ConfigService) => config.get('database'),\n inject: [ConfigService],\n }),\n ],\n})\nexport default class AppModule {}\n```\n\nYour config file may look something like this:\n\n```ts\n//config/database.ts\nexport default {\n type: 'mysql',\n host: process.env.TYPEORM_HOST,\n username: process.env.TYPEORM_USERNAME,\n password: process.env.TYPEORM_PASSWORD,\n database: process.env.TYPEORM_DATABASE,\n port: parseInt(process.env.TYPEORM_PORT),\n logging: process.env.TYPEORM_LOGGING === 'true',\n entities: process.env.TYPEORM_ENTITIES.split(','),\n migrationsRun: process.env.TYPEORM_MIGRATIONS_RUN === 'true',\n synchronize: process.env.TYPEORM_SYNCHRONIZE === 'true',\n};\n```\n\n> We recommend using a `TYPEORM_` prefix so when running in production environments you're also able to use the same envs for running the typeorm cli. [More options here](http://typeorm.io/#/using-ormconfig/using-environment-variables)\n\n## Custom env file path\n\nTo use dotenv options, you will need to install `@types/dotenv` by running\n\n```bash\n$ yarn add --dev @types/dotenv\n```\n\nNow you can specify dotenv options with the second parameter of the load method\n\n```ts\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(__dirname, '..', '.env.staging')),\n});\n```\n## TypeORM config with DI + types\n\n```ts\n//config.database\nexport class DatabaseConfig {\n type: 'mysql' | 'postgres' = 'mysql';\n host: string = process.env.TYPEORM_HOST;\n username: string = process.env.TYPEORM_USERNAME;\n password: string = process.env.TYPEORM_PASSWORD;\n name: string = process.env.TYPEORM_DATABASE;\n port: number = parseInt(process.env.TYPEORM_PORT);\n logging: boolean =\n process.env.TYPEORM_LOGGING === 'true' || process.env.TYPEORM_LOGGING === 1;\n entitites: string[] = process.env.TYPEORM_ENTITIES.split(',');\n migrationsRun: boolean = process.env.TYPEORM_MIGRATIONS_RUN === 'true';\n synchronize: boolean = false;\n}\n```\n\n```ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule, ConfigService } from 'nestjs-config';\nimport { TypeOrmModule } from '@nestjs/typeorm';\nimport { DatabaseConfig } from './config/database';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.forRootAsync(\n path.resolve(__dirname, 'config', '**', '!(*.d).{ts,js}'),\n ),\n TypeOrmModule.forRootAsync({\n useFactory: (config: DatabaseConfig) => config,\n inject: [DatabaseConfig],\n }),\n ],\n})\nexport default class AppModule {}\n```\n\n## Using different env files\n\nCreate a `.env` file at the root directory of your application had always been the best practice.\nYou could also create custom .env file per different environments.\n\n```bash\n# .env\nEXPRESS_PORT=3000\n\n# .env.dev\nEXPRESS_PORT=3001\n\n# .env.testing\nEXPRESS_PORT=3002\n\n# .env.staging\nEXPRESS_PORT=3003\n```\n\n```ts\nconst ENV = process.env.NODE_ENV;\n\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(process.cwd(), !ENV ? '.env' : `.env.${ENV}`),\n});\n```\n\nPerhaps you need a custom directory to manage env files.\n\nIn this example, the name of the custom directory is `env`.\n\n```bash\n/\n├── dist/\n├── env/\n│ ├── .env.dev\n│ ├── .env.testing\n│ └── .env.staging\n│ │\n├── src/\n│ ├── config/\n│ │ └── typeorm.config.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\n```ts\nconst ENV = process.env.NODE_ENV;\n\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(process.cwd(), 'env', !ENV ? '.env' : `.env.${ENV}`),\n});\n```\n\n> **Note:** If you place env files inside an `src` directory, you won't be able to see env files included as a final output in `outDir` since TS compiler will never transpile files that do not match with \\*.ts extension.\n\n## Support\n\nAny support is welcome. At least you can give us a star :star:\n\n## Contributors\n\n### Code Contributors\n\nThis project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)].\n\n![](\"https://opencollective.com/nestjsx/contributors.svg?width=890&button=false\")
\n\n\n## ConfigService API\n\n#### get\n \n \n \n \n \n \n
\n
\n \n \n \n \n
Configuration component for NestJs.
\n\n\n## Features\n\n- Load your configuration files using globs\n- Support for different environment configurations, thanks to [dotenv](https://github.com/motdotla/dotenv)\n- Change and Load configuration at runtime\n\n### Installation\n\n**Yarn**\n```bash\nyarn add nestjs-config\n```\n\n**NPM**\n```bash\nnpm install nestjs-config --save\n```\n\n### Getting Started\n\nLet's imagine that we have a folder called `src/config` in our project that contains several configuration files.\n\n```bash\n/src\n├── app.module.ts\n├── config\n│ ├── express.ts\n│ ├── graphql.ts\n│ └── grpc.ts\n```\n\nLet's register the config module in `app.module.ts`\n\n```ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.load(path.resolve(__dirname, 'config', '**/!(*.d).{ts,js}')),\n ],\n})\nexport class AppModule {}\n```\nThat's it!\n\n-----\n\n#### Complex Project Structure\n\nNow let's say that your application isn't located in a folder called `src`, but it's located in `src/app`.\n\nWe want to be able to set a different 'root path' to load our configurations from. Be it `src` or `dist`.\n\nImagine a more complex project structure like this:\n\n```\n/\n├── dist/\n├── src/\n│ ├── app/\n│ │ ├── app.module.ts\n│ │ └── bootstrap/\n│ │ │ ├── index.ts\n│ │ │ └── bootstrap.module.ts\n│ ├── migrations/\n│ ├── cli/\n│ ├── config/\n│ │ ├── app.ts\n│ │ └── database.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\nIn this example, config files are located in the `/src/config` folder, because they are shared \nbetween app, migrations and cli scripts. \n\nAlso during typescript compilation all files from `src/` folder will be moved to the `dist/` folder. \n\nMoreover, the `ConfigModule` is imported in the `BootstrapModule`, but not directly in `AppModule`.\n\n```ts\n// app.module.ts\nimport { Module } from '@nestjs/common';\nimport { BootstrapModule } from './bootstrap';\nimport { ConfigService } from 'nestjs-config';\n\nConfigService.rootPath = path.resolve(__dirname, '..');\n\n@Module({\n imports: [BootstrapModule],\n})\nexport class AppModule {}\n```\n\n```typescript\n// bootstrap.module.ts\nimport * as path from 'path';\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\n\n@Module({\n imports: [\n ConfigModule.load(path.resolve('config', '**/!(*.d).{ts,js}')),\n ],\n})\nexport class BootstrapModule {}\n```\nSetting the `ConfigService.rootPath` before calling `ConfigModule.load(...)` will change the default root dir of where your configs are loaded from.\n\nAnother method is to invoke `ConfigModule.resolveRootPath(__dirname)` from any module before loading the config and use glob with a relative path.\n ```ts\n // bootstrap.module.ts\n import { Module } from '@nestjs/common';\n import { ConfigModule } from 'nestjs-config';\n \n @Module({\n imports: [\n ConfigModule.resolveRootPath(__dirname).load('config/**/!(*.d).{ts,js}')\n ],\n })\n export class BootstrapModule {}\n ```\n\nIn both cases we provide the glob of our configuration as first argument, but it is relative to the `src/` folder (or eventually `dist/`).\n\n## Multi-modular config usage\n\nIn some cases your structure might take on this shape\n\n```\n/\n├── src/\n│ ├── cats/\n│ │ ├── cats.module.ts\n│ │ └── cats.config.ts\n│ ├── dogs/\n│ │ ├── dogs.module.ts\n│ │ └── dogs.config.ts\n│ ├── app.module.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\nWith the examples above you'd have to call your config like so `ConfigService.get('dogs.config.bark')`. You can use the `modifyConfigName` method option to change the name of your configs \n\n```ts\nimport { Module } from '@nestjs/common';\nimport { ConfigModule } from 'nestjs-config';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.load(path.resolve(__dirname, '**/!(*.d).config.{ts,js}'), {\n modifyConfigName: name => name.replace('.config', ''),\n }),\n ],\n})\nexport class AppModule {}\n```\nNow you can call your config like so `ConfigService.get('dogs.bark')`.\n\n## Production environments\n\nYou might have notice the use of `config/**/!(*.d).{ts,js}` in the glob. When running in production (running in JavaScript after TypeScript compilation) we want to disinclude the TypeScript definition files. The use of `config/**/*.ts` is fine in dev environments but we recommend using this example `config/**/!(*.d).{ts,js}` to avoid issues later on when running in a production environment.\n\n## Environment Configuration\n\nThis package ships with the amazing [dotenv](https://github.com/motdotla/dotenv) package that allows you to create\na `.env` file in your preferred location.\n\nLet's create one, for demo purposes!\n\n```bash\n# .env\nEXPRESS_PORT=3000\n```\n\nNow, in our `src/config/express.ts` configuration file, we can refer to that environment variable.\n\n```ts\n// src/config/express.ts\nexport default {\n port: process.env.EXPRESS_PORT || 3000,\n}\n```\n\n> **Note:** By default the package look for a `.env` file in the path that you have started your server from.\nIf you want to specify another path for your `.env` file, use the second parameter of `ConfigModule.load()`.\n\n\n### Usage\n\nNow we are ready to inject our `ConfigService` anywhere we'd like.\n\n```ts\nimport {ConfigService} from 'nestjs-config';\n\n@Injectable()\nclass SomeService {\n\n constructor(private readonly config: ConfigService) {\n this.config = config;\n }\n \n isProduction() {\n const env = this.config.get('app.environment');\n \n return env === 'production';\n }\n}\n```\n\nYou may also use the `@InjectConfig` decorator as following:\n\n```ts\nimport {InjectConfig} from 'nestjs-config';\n\n@Injectable()\nclass SomeService {\n\n constructor(@InjectConfig() private readonly config) {\n this.config = config;\n }\n}\n```\n\n## Custom Helpers\nThis feature allows you to create small helper function that computes values from your configurations.\n\nReconsider the `isProduction()` method from above. But in this case, let's define it as a helper:\n\n```ts\n// src/config/express.ts\n\nexport default {\n\n environment: process.env.EXPRESS_ENVIRONMENT,\n port: process.env.EXPRESS_PORT,\n \n // helpers\n isProduction() {\n return this.get('express.environment') === 'production';\n }\n}\n```\n\nYou can use the helper function as follows:\n\n```ts\n// this.config is the ConfigService!\nthis.config.get('express').isProduction();\n\n// or\nthis.config._isProduction(); // note the underscore prefix.\n```\n\n#### Global Helpers\n\nYou can also attach helpers to the global instance as follow:\n\n```ts\nthis.config.registerHelper('isProduction', () => {\n return this.get('express.environment') === 'production';\n});\n```\n\nAnd then use it like this:\n\n```ts\nthis.config.isProduction(); // note the missing underscore prefix\n```\n\n## Decorators \n\nIt's possible to use decorators instead of injecting the `ConfigService`. \nNote that the `@Configurable()` decorator replaces the `descriptor.value` for the\nmethod with its own function. Regarding to the current nestjs implementation\n([Issue-1180](https://github.com/nestjs/nest/issues/1180)), this behavior will \nbreak all decorators that **FOLLOW AFTER** the `@Configurable()` decorator.\n\nFor the expected behavior, the `@Configurable()` decorator **MUST** be placed at \nthe last position for one method.\n\n**Working Example:**\n```ts\nimport {Injectable, Get} from '@nestjs/common';\nimport {Configurable, ConfigParam} from 'nestjs-config';\n\n@Injectable()\nexport default class UserController {\n \n @Get('/')\n @Configurable()\n index(@ConfigParam('my.parameter', 'default value') parameter?: string) {\n return { data: parameter };\n }\n}\n```\n\n**Broken Example:**\n```ts\nimport {Injectable, Get, UseInterceptors} from '@nestjs/common';\nimport {Configurable, ConfigParam} from 'nestjs-config';\nimport {TransformInterceptor} from '../interceptors';\n\n@Injectable()\nexport default class UserController {\n \n @Configurable()\n @Get('/') // <-- nestjs decorator won't work because it placed after @Configurable()\n @UseInterceptors(TransformInterceptor)// <-- nestjs decorator won't work because it placed after @Configurable()\n index(@ConfigParam('my.parameter', 'default value') parameter?: string) {\n return { data: parameter };\n }\n}\n```\n\n**Broken Example 2:**\n```ts\nimport {Injectable, Get, UseInterceptors} from '@nestjs/common';\nimport {Configurable, ConfigParam} from 'nestjs-config';\nimport {TransformInterceptor} from '../interceptors';\n\n@Injectable()\nexport default class UserController {\n \n \n @Get('/') // <-- nestjs decorator will work fine because it placed before @Configurable()\n @Configurable()\n @UseInterceptors(TransformInterceptor) // <-- nestjs decorator won't work because it placed after @Configurable()\n index(@ConfigParam('my.parameter', 'default value') parameter?: string) {\n return { data: parameter };\n }\n}\n```\n\n## TypeORM \n\nUsing the `ConfigModule` in combination with [TypeORM](https://github.com/typeorm/typeorm) (e.g. in order to configure TypeORM) requires using the `forRootAsync()` function supplied by the typeorm package for nestjs (`@nestjs/typeorm`)\n\n```ts\nimport {Module} from '@nestjs/common';\nimport {ConfigModule, ConfigService} from 'nestjs-config';\nimport {TypeOrmModule} from '@nestjs/typeorm';\nimport * as path from 'path';\n\n@Module({\n imports: [\n ConfigModule.load(path.resolve(__dirname, 'config', '**', '!(*.d).{ts,js}')),\n TypeOrmModule.forRootAsync({\n useFactory: (config: ConfigService) => config.get('database'),\n inject: [ConfigService],\n }),\n ],\n})\nexport default class AppModule {}\n```\n\nYour config file may look something like this: \n\n```ts\n//config/database.ts\nexport default {\n type: 'mysql',\n host: process.env.TYPEORM_HOST,\n username: process.env.TYPEORM_USERNAME,\n password: process.env.TYPEORM_PASSWORD,\n database: process.env.TYPEORM_DATABASE,\n port: parseInt(process.env.TYPEORM_PORT),\n logging: process.env.TYPEORM_LOGGING === 'true',\n entities: process.env.TYPEORM_ENTITIES.split(','),\n migrationsRun: process.env.TYPEORM_MIGRATIONS_RUN === 'true',\n synchronize: process.env.TYPEORM_SYNCHRONIZE === 'true',\n};\n```\n\n> We recommend using a `TYPEORM_` prefix so when running in production environments you're also able to use the same envs for running the typeorm cli. [More options here](http://typeorm.io/#/using-ormconfig/using-environment-variables)\n\n## Custom env file path\n\nYou can specify dotenv options with the second parameter of the load method\n\n```ts\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(__dirname, '..', '.env.staging')),\n});\n```\n\n## Using different env files\n\nCreate a `.env` file at the root directory of your application had always been the best practice.\nYou could also create custom .env file per different environments.\n\n```bash\n# .env\nEXPRESS_PORT=3000\n\n# .env.dev\nEXPRESS_PORT=3001\n\n# .env.testing\nEXPRESS_PORT=3002\n\n# .env.staging\nEXPRESS_PORT=3003\n```\n\n```ts\nconst ENV = process.env.NODE_ENV;\n\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(process.cwd(), !ENV ? '.env' : `.env.${ENV}`),\n});\n```\n\nPerhaps you need a custom directory to manage env files.\n\nIn this example, the name of the custom directory is `env`.\n\n```bash\n/\n├── dist/\n├── env/\n│ ├── .env.dev\n│ ├── .env.testing\n│ └── .env.staging\n│ │\n├── src/\n│ ├── config/\n│ │ └── typeorm.config.ts\n│ └── main.ts\n├── tsconfig.json\n└── package.json\n```\n\n```ts\nconst ENV = process.env.NODE_ENV;\n\nConfigModule.load(path.resolve(__dirname, '*/**!(*.d).config.{ts,js}'), {\n path: path.resolve(process.cwd(), 'env', !ENV ? '.env' : `.env.${ENV}`),\n});\n```\n\n> **Note:** If you place env files inside an `src` directory, you won't be able to see env files included as a final output in `outDir` since TS compiler will never transpile files that do not match with \\*.ts extension.\n\n## Support\n\nAny support is welcome. At least you can give us a star :star:\n\n## Contributors\n\n### Code Contributors\n\nThis project exists thanks to all the people who contribute. [[Contribute](CONTRIBUTING.md)].\n\n\n\n\n## ConfigService API\n\n#### get(param: string | string[], value: any = undefined): any\nGet a configuration value via path, you can use `dot notation` to traverse nested object. It returns a default value if the key does not exist.\n\n```ts\nthis.config.get('server.port'); // 3000\nthis.config.get('an.undefined.value', 'foobar'); // 'foobar' is returned if the key does not exist\n```\n\n#### set(param: string | string[], value: any = null): Config\nSet a value at runtime, it creates the specified key / value if it doesn't already exists.\n\n```ts\nthis.config.set('server.port', 2000); // {server:{ port: 2000 }}\n```\n\n#### has(param: string | string[]): boolean\nDetermine if the given path for a configuration exists and is set.\n\n```ts\nthis.config.has('server.port'); // true or false\n```\n\n#### merge(glob: string, options?: DotenvOptions): Promise