[Feature]: Improve dotenv to store local API keys, etc

[seriouslysean]

Already added it but there's likely a better way to use it. Ideally I'd love to split the logic and have dev usages use it, and then prod usages require envs in github to be run solely through github actions.

[divyansh-4]

Hey @seriouslysean , could you tell me a little more about what you need with this, so I could let you know if I could be of any help.

[seriouslysean]

@divyansh-4 sure, the idea for this issue is to better organize how dotenv is being used. Right now I used it all over the place for every call, though I'm not sure that's the best way to do it.

It seems like there needs to be a logic split between how we run run it:

• locally (on your machine), for testing and such
• remotely, via a github workflow (the intended way I'd like this to run)

That second way is where I don't think dotenv would be needed at all since all envs would be provided as GitHub secrets.

[divyansh-4]

Hey, I do remember going through an article on stack overflow for a similar issue. I could take this up and give it a shot. However, i would need some help in getting it up and running locally. In any scenario, here's a link to the thread: https://stackoverflow.com/questions/60176044/how-do-i-use-an-env-file-with-github-actions

[seriouslysean]

@divyansh-4 I think it might be even easier than that! Lets take one of these tools as an example from the package.json:

"fetch:article": "node -r dotenv/config ./tools/fetch-article.js",

Instead of using dotenv inline, I think it might be better to move to a call without it, node ./tools/fetch-article.js but that would break the local runs so I see two potential solutions:

1. Forking the tool in to two calls

"fetch:article": "node -r dotenv/config ./tools/fetch-article.js",
"prod:fetch:article": "node ./tools/fetch-article.js",

In this case, I would only run the prod version in the github actions which would rely on preset secrets.

1. Move the dotenv call in to the app and tools

"fetch:article": "node ./tools/fetch-article.js",

Then in the files do something like this

require('dotenv');

Then we could add a NODE_ENV env and use that in the prod scenarios. See https://www.npmjs.com/package/dotenv for more examples.

---

If I had to pick, I'd stick with number 2 because it feels more flexible and less verbose to me. You'd also be able to test locally by running the script in multiple ways.

Local

npm run fetch:article -- -u <url>

Prod

NODE_ENV=production npm run fetch:article -- -u <url>

[seriouslysean]

@divyansh-4 are you still interested in this issue?