brave-browser: Don't use npm config for app environment variables

Using .npmrc to store environment variables for the local app is a bit of a misuse, and can be confusing for developers. Also, as of npm v9, using npm config to set custom variables is not supported.

Instead we can use the popular practice of .env files. We can use the dotenv package (https://www.npmjs.com/package/dotenv) to read from the .env file, and we can store an empty (or default values) .env file in the repo.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 2
  • Comments: 25 (18 by maintainers)

Most upvoted comments

@goodov if we go for aws secrets manager, we can either use the js sdk, or just invoke the aws cli from js, since it’s a one-liner to fetch a secret.

But I’m wondering, do we really need all this? What if we saved all the secrets as a single item in 1password and just let people save it to disk? Doesn’t matter if it’s .npmrc, or some other type of file.

Fetching from a proper secrets store would have some undeniable upsides - we wouldn’t have to save the secrets to disk and there would be no manual updates needed. But it would be way more complex and would introduce a number of new potential failure causes into the mix…

re: hashicorp vault, we do use it already in https://github.com/brave-intl/bat-go. i’m guessing @husobee knows more about how that is set up. however that is another dependency (one that most devs here don’t already use) that has had known vulnerabilities in the past that required urgent updating - https://www.cvedetails.com/vulnerability-list/vendor_id-16814/product_id-70468/Hashicorp-Vault.html

since DevOps have to maintain it prioritize their opinion over mine. AWS secrets manager is just as secure for these use cases as Hashicorp vault in this case, so I’d have no problem with either of them.

Well, one can commit a .env.example file if we go down this route. Filling process.env is the same thing that .npmrc does with npm run ... commands AFAIK.

from FAQ https://www.npmjs.com/package/dotenv:

Should I commit my .env file? No. We strongly recommend against committing your .env file to version control. It should only include environment-specific values such as database passwords or API keys. Your production database should have a different password than your development database.

dotenv’s main use case seems to fill process.env (effectively pollute environment for all child processes) which is not great IMO. It doesn’t support $HOME/.env lookup or a parent directory .env merge.

There’re some options to use find-config, but they are not perfect.