-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use process.env for PORT #125
Comments
I also just wanted to thank the contributors of this project for working towards addressing the lack of strong convention in the Node server-side ecosystem ❤️ |
@erikkrieg Please review an example in nestjs/nest#1573 |
Thank you @erikkrieg. Just to explain. Using |
I am unsure why the issue has been closed. Might be a misunderstanding on what I was trying to communicate, or perhaps something I am missing about the CLI. I don't really know this framework well enough to have an opinion on how this project handles configuration so I referred to the To clarify the issue I was pointing to, my concern is that the CLI creates a new project that lacks a good convention for handling configuration. In this case, the port that the server listens on. This implicitly promotes an anti-pattern and misses an opportunity to share the opinions that project already seems to have on how to handle configuration. The Node ecosystem is sorely missing a strong, opinionated framework like what Rails is to Ruby. I hope that this project is aspiring to fill that void. I think having the CLI get devs started without having to think about setting conventions like this helps get there. |
Well, that might be a good thing actually. I thought you wanted to suggest the usage of the
(instead of just hardcoded port) |
Yeah, that is a step in the direction I was trying to communicate. Ofc it is up to the maintainers to determine how sophisticated the handling of config in the "basic" project generated from the CLI should be. |
Hey firstly @kamilmysliwiec, great job on this project; I'm enjoying working with it :). Using something like I've happened to solve this for our custom schematic that extends this in order to add some business specifics. By utilizing environments files(As Angular does) and schema properties in combination, we are able to generate and run multiple nest apps straight from the cli with no additional config. I think something along these lines could provide an elegant solution. Example: We set the environment.prod file to expose a server_port property to a environment variable. And in the dev environment file we used a port chosen at the generate stage. The schema.json sets the default and prompts for a choice In our main.ts we just import |
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 |
@felixhayashi yes this works ....thank you so much, especially the fact that node-config has a feature of |
Many people use .env but I have been not saw who think about why we should use .env at first time and why there are people that use as Of source, I can understand always setting vars is to be tedious too (or maybe we should patch encrypted vars dynamically with big working). Moreover, Nowadays on javascript, pm2 is used on dev / staging env normally. Maybe you don't need to use .env except on local env. |
|
I have gone through official nestjs documentation. Here is what should be done import { ConfigService } from '@nestjs/config'; const port = configService.get('PORT'); in .env In app.module.ts , import config module if not done ;-) |
I'm submitting a...
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.
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:
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 thatsrc/main.ts
has hardcoded port.What is the motivation / use case for changing the behavior?
Two motivations for this feature request:
Environment
The text was updated successfully, but these errors were encountered: