Been learning backend and recently got this question about .env file. I figured that’s the standard place to name secret stuff, like your API keys, ports, password, etc. And hiding it so others wont see it on github.
I know it’s a standard practice and it’s easy to figure out where all the secret stuff are located without having to look for a file. But i’m still wondering if there might be something more to it.
An environment variable is a variable stored on the system, accessible to applications that run via the shell (Node applications, for example). It wouldn’t make much sense for them to be in a .js file, most things on the system are unlikely to understand JS. The point is that they aren’t tied to any specific language runtime, they’re tied to the system (runtime of one specific computer) itself
.env is just a convention for a common type of library that exists for almost all languages: application-specific variables are defined in a .env file in the project, and the library takes care of writing those to the system environment so that you don’t have to do it manually yourself (+ normally allowing it to work across different OS’, which may have different ways of defining environment variables)
Agreeing 100% with Dan, but in theory you could do your environment files in a JS file and just add it to the gitignore. It’s just not the best practice.
I do use JS files for some constants that only the app needs but I want to keep them in one place. But anything that is sensitive, they go in an env file.
very nice answer thanks @DanCouper
and @kevinSmith yeah, that’s what i thought, you could use the js file.
I would say, though, that while you could use a
.js file and add it to your
.gitignore, that’s got so much potential for extra headache that it doesn’t seem worth it.
Many PaaS platforms, such as Heroku and Glitch, offer native integration for the
.env values. If I need to add a key, I can do so directly in their GUI - no messing around with my CD through GitHub.
.js file would remove that functionality, and would require additional steps for configuring a production environment. I, personally, don’t see the use case.
Yes, just to be clear, I’m not advocating that. But for things that only used in my app and are not sensitive - I don’t bother. I was working on a team where there env file was several hundred lines long - most of which were just constants for the app and urls without any sensitive data - that seemed insane to me. But true environment variables and anything sensitive, definitely in the env file.
I can definitely agree with that.
For non-secret constants, I’ll slap together a
.json file and import it, usually.
(for non-secret variables that I want to change on the fly, I’ll sometimes use the .env because it means I don’t have to modify the code)