Add dotenv dependency

[sayhiben]

The command line options are growing verbose, and it would be nice to
maintain the same settings while also not having to specify the entire
configuration in either the call to the command or by specifying them
in the environment

This commit adds a new dependency, dotenv, which allows users to copy
the provided sample.env file to ./.env and customize it themselves

Also updates .gitignore to support Jetbrains IDEs and commits the
package-lock.json to ensure dependency version consistency

[chromakode]

Awesome, thanks @sayhiben! I have been feeling similarly about the proliferation of options. It's time to adopt a more scalable pattern.

FYI I have been configuring these scripts using systemd unit files, and would suggest others running these scripts in production use an equivalent service configuration / supervisor tool.

I've been thinking about switching to yargs, similar to streamwall, so that an optional config file and parameters is supported (here's how streamwall implements it). I have considered using .env files for this, but it seems like yargs provides a few advantages:

• separate config files for multiple configurations
• control over config parsing (I've been thinking about switching to TOML for easy writing)
• param descriptions/--help output

yargs can also consume environment variables.

Would you be interested in taking this on?

[sayhiben]

I agree - yargs is likely the right solution. I'm actually in the middle of solving a different challenge with this repo (evaluating live status of profiles instead of discrete videos). This was a quick and dirty implementation meant to provide a stepping stone; if you'd rather move to yargs, I fully support it. If I'm honest, I don't have bandwidth to handle anything outside of my critical path right now, although normally I'd take you up on the offer to implement. I'm happy to keep this in my fork for the time being if that's preferable to taking on the debt of refactoring it later

…

On Sun, Jun 28, 2020 at 3:22 PM Max Goodhart ***@***.***> wrote: Awesome, thanks @sayhiben <https://github.com/sayhiben>! I have been feeling similarly about the proliferation of options. It's time to adopt a more scalable pattern. FYI I have been configuring these scripts using systemd unit files, and would suggest others running these scripts in production use an equivalent service configuration / supervisor tool. I've been thinking about switching to yargs <https://www.npmjs.com/package/yargs>, similar to streamwall <https://github.com/chromakode/streamwall>, so that an optional config file and parameters is supported (here's how streamwall implements it <https://github.com/chromakode/streamwall/blob/1087c6855e3e6546d0260d9c260baf71caeebc9c/src/node/index.js#L13-L15>). I have considered using .env files for this, but it seems like yargs provides a few advantages: - separate config files for multiple configurations - control over config parsing (I've been thinking about switching to TOML for easy writing) - param descriptions/--help output yargs can also consume environment variables <https://yargs.js.org/docs/#api-envprefix>. Would you be interested in taking this on? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFFX2SAM2RFMDPGW2XC4BLRY67BRANCNFSM4OKW4TJA> .