-
Notifications
You must be signed in to change notification settings - Fork 27
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
Consider using a better env file library #91
Comments
I am actually a fan of envy. If we did decide to go that direction, could we contribute to update envy's tests for some recent versions of node? (I realize even dotenv's test suite is a little bit behind too!) What do others think? Here are some additional thoughts:
|
I created The workflow went something like this:
I prefer to look at this not as a problem with the developer but as a problem with the system. It was too easy to make this mistake. In some sense, this is actually a failing of the Thus,
Amazingly, no other library does these checks. Even
There are two main ways secrets could end up in the repo, both of which
Correct.
Yes,
At the moment,
Agreed. There's no need for
I care a lot about dependencies. I thoroughly investigate all of my dependencies, including deeply nested ones, and aim to read and understand all of their code. No small task. One of the ways I make this manageable is to only use modules by Sindre Sorhus, when possible. He keeps his code lean and simple. Here is the entire dependency tree for ❯ npm ls --production
envy@2.0.0 /Users/sholladay/Code/personal/envy
├── camelcase@5.3.1
├─┬ camelcase-keys@5.2.0
│ ├── camelcase@5.3.1 deduped
│ ├── map-obj@3.1.0
│ └── quick-lru@1.1.0
├── filter-obj@1.1.0
├── is-wsl@1.1.0
└─┬ path-type@3.0.0
└── pify@3.0.0 Every single one of these modules is made by Sindre. They are actively maintained, stable, and have high quality tests, documentation, etc. Also notice that most of them are simply utilities that arguably ought to be in JavaScript's standard library. The
Awesome, well it's definitely meant to play nicely with hapi. One of the things I strongly dislike about the Express ecosystem is the prevalent use of |
I think it's overall a good idea, having a "safer" default is always good (plus it follows the hapi "way") My only struggle when using
Because I mostly want to use |
My suggested workaround is to either:
These solutions aren't as bad as they might sound because I would urge you to only do the above for simple, non-sensitive config values like a |
That's mostly what I do indeed, using |
@sholladay I am playing with envy in a baseline pal boilerplate, and am running into an issue I can't resolve myself: the boilerplate only has one env variable ( |
At the time I was thinking that an empty example file would likely be a mistake. But your use case seems valid. Let's remove that assertion. PR welcome. I'm happy to help work on this if you run into any issues, but I'm currently in the process of selling my house so fairly busy for a few weeks. |
Just an update here for those interested: I am favoring an eventual move to envy, but there are some loose ends regarding Windows support that are still in progress, and I don't expect it to land for the upcoming version of the boilerplate. Before moving to envy I would also like to alter how environment variables are handled in confidence, and that work is also in progress but not finalized. Here are the relevant issues: sholladay/envy#4 sholladay/envy#8 hapipal/confidence#106 hapipal/confidence#110. |
The boilerplate currently uses the
dotenv
package, which is less than ideal because it's easy to make mistakes with it and accidentally commit secrets to the git repository, among other issues.It would be great if the boilerplate could use a safer library, such as envy or dotenv-safe, which provide various levels of validation.
The text was updated successfully, but these errors were encountered: