Whenever it comes to securing the API keys or something that we don't want to be exposed to the public for our Open Source Project, we always tend ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Nice work so far and thanks for sharing but however your article did not : (1) state the problem as the title suggest . (2) security measures (3) Alternative and best adoptable practice . What you demonstrate is just changinge file name . Keep up the good work we look forward to get more details from you so we all can benefit.
No, the demonstration is that the
dotenvmiddleware package is wholly unnecessary and that Node.js itself implements the desired functionality without having to download and install additional third-party middleware.Pay attention.
ok thanks for the clarification.
I like the honest critique.
Feel free to take a look at my latest article and let me know what you think.
dev.to/dansasser/supercharge-your-...
.env file is never committed to the repo, thus not exposing your secrets. As far as using variables in prod, it doesn't really matter, you could inject .env file into the container at build time/ssh into the virtual machine and define it if you are solo, you just have to be careful that there is no way that the file could ever leak.
I never understood why not including a
.envto the repo. For me a.envis a source for a sane default setup. Of course I would agree not to commit any secrets. And if you want to work with local settings you would copy.envto.env.localand set your custom settings there. Or in prod you would have.env.prod(which of course you won't commit either).Am I doing things wrong?
I can agree on _ not committing secrets_ but that is different from _not commiting
.env.You can start with .env.default and set up your variables there, and commit that to source control. Then make a copy of it with your local values and name it .env, and add that file to .gitignore. The default file acts as a template for the external environment values, and the values are still private. Win win!
I use
.env.example,.env.development.example, etc. and add those to the repo, with sane defaults in them, or comments on how to get the right variables. This prevents accidental commits.AFAICS this introduces one extra step: copy
.env.exampleto.env. As.env.exampleis not loaded by default?Take a look at npmjs.com/package/envalid.
It's a great package for defining your default config which can be committed to source control.
You can then override the config with environment variables.
It makes things easy easier for new devs to get started because they have all the default config they need (except any secrets) and has a centralised place for seeing what config the app requires.
I used to use envalid for everything but honestly found myself a bit frustrated with it recently; Nextjs projects in particular don't seem to be compatible. Very frustrating.
Most projects by default don't commit
.env.localto a repo. You can simply edit the.gitignorefile to change whether or not your custom file or the.envfile is committed.No need for me to it now😁
I would understand if this all was due to some security concerns, but really if someone got access for reading.
.envfile he has access for everything else...As for me naming files with environment variables is mostly conventional approach.
if that's a bold try to obfuscate the existence of API Key values inside a .env by moving them to a different file... let me tell you that if someone has access to your .env they also have access to your package.json and probably to your server processes as well. If it were me I could just ask the node terminal what
process.envcontains 🤷🏼♀️This article is not talking about not to use .env file, but not to use dotenv npm package.
Sure but it doesn't explain why you shouldn't use it. Have I missed anything?
Well, then the title is just bad - as it contains the word "file"…
It says "package", not "file"
Maybe he edited it?
The punchline about replacing the package with a CLI arg was in the last paragraph, so I wonder if most people missed it.
yes it has been edited but anyway.... the recommended way would probably be using dotenvx mostly for the encrypt stuff
Like the other people, what was the problem using .env as filename ? As someone has told, such file isn't part of the repository and shouldn't contains secrets but just configuration items.
In your suggestion, you've named the file "manas" so, without extra security feature, I will be able to access the file using a URL and see his content.
At least name it .manas, don't you think ?
This article is not talking about not to use .env file, but not to use dotenv npm package.
You're basically saying "stop using React, because look, you can do everything React can with pure JS. It's just a trendy library that nobody needs to use."
dotenv offers a lot of additional features such as variable expansion, default values, and multi-line values. There's a reason it's got 29 million weekly downloads.
Clickbait at it's best.
We really need content moderation against these cheap and title defying contents that people write just to add to their resumes that they write content. This is not okah.
I hope you could have read the article before writing the content.
I read the article multiple times before commenting to ensure I'm not misreading anything.
How in the world does renaming a .env file have to do with dotenv package. Then, you present the ability to use nodejs natively to read the file which is 🦾, but then, you do not specify the constraints.
You have not specified why to use your approach.
My advice
Please try to sit down and learn about content writing. it would benefit a lot.
Can you please share a content that you wrote, so I can learn ?
Well i go with his idea. Because most sever technology now have their own variable security, for example vercel.com which will tell you to add each content or variable constant inside .env to their own security guild(i don't know the proper name for it) for proper security. You get me right 👍
Good article, too bad there's too many trolls here that are not discussing the main point of your article. It's in the title people.
Only thing I would add is Node.js began supporting .env files starting with version 20.6.0, so if you're using a version that's anything before that you'll still need to download third party packages like dotenv.
Point is you don't need to install a third party app anymore for a built in supported feature. This article is relevant because still many people are unaware of this.
This article is not talking about not to use .env file, but not to use dotenv npm package.
I think you meant 29m+
Yeah, My mistake :)
So your article is about "Don't use .env, use any other name", correct?
No, Its all about not to use dotenv as a package
...or take a look at dotenvx...
such a click bait, content is so poor, which diminishes the blog's appeal.
stop using dotenv, but start using dotenvx :)
github.com/dotenvx/dotenvx
did this happen just to me or its a known bug?
a .env file constants return the values saved in the file on linux but on windows, it gets older values.
I love those polemics posts they are the ones which grab more attention
I don’t get it.. are you saying don’t use dotenv because we can access .env files without the library? That’s true of any library.
I don't get it, what problem is this solving?
Don't commit sensitive files to the repo or use GH secrets, Vault etc.
Also you could've given an example with a token or password and not PORT.
Its not solving a specific problem @nikko1350 , I wrote this article just to aware that dotenv package is not necessary for the node.js. We can call the environment file even without this specific package.
Judging by the comments, maybe the title should have been "NodeJS: is the dotenv package redundant?"
Tbh, the title makes it sound like there's something wrong with the package and you are about to explain it to us, so I don't have any problems with the content.... But I do feel like I've been tricked into coming here.
I also feel that many node packages have massive package dependencies and trimming down one that is prominent, well supported and (in most cases) actually useful isn't necessary as there's probably a few hundred packages being included in the project that you aren't actively monitoring.
But you aren't wrong, any file containing secrets can be referenced without the dotenv package.
These "You need to stop using ____" articles are goofy. If something works for you, use it.
.env secrets are stored as plain text right!? And i have something in my mind, that is. Is there any better way to store the .env variables securely, any other option for that along with python.
The obvious thing would be the deterministic nature on what overrides the value... i e. OS runtime env vars will supercede them. Which is normally what you want