cli executable

[falkenhawk]

Hi Dan, I'd like to introduce a cli executable which would work similar to https://www.npmjs.com/package/dotenv-cli (calling a command from the argv after setting ENV), but load dotenv-flow internally and possibly those -e and -p options. My use case: calling k6 from cli with dotenv-flow k6 -- run load-tests.js

It would be a simple script, but will probably come with additional dependencies (cross-spawn and minimist, ...and maybe, just maybe dotenv-expand 🤔 although I personally don't need it atm)

Would you prefer to have it as a separate package dotenv-flow-cli or rather integrated into this repo? Maybe you have an idea how to do it better - with less or no dependencies? (to keep the zero-dependency policy)

[kerimdzhanov]

Hi Maciej,

Sounds good! I think it would be better to have a separate package, and that's why:

I want to keep dotenv-flow as lightweight as possible. Actually, I was planning to remove the dotenv module from dependencies, implementing the .parse() method as a part of this module, thus making it really zero-dependent.

As for the executable like dotenv-cli, I think it's not possible (at least not reasonable) to implement it without adding some dependencies.

[falkenhawk]

I've put it together quickly: https://github.com/ovos/dotenv-flow-cli Let me know please if you are fine with it, so I could transfer it to your username.

[kerimdzhanov]

The first thing I would recommend is to name the executable dotenv-flow instead of dotenv, I believe that it's already reserved by dotenv-cli.

The second is: I can't imagine the situation when somebody needs to install that package locally (I mean not globally). If somebody installs it as a dependency to their own project, they would like to have their own executable, and it's more reasonable to simply require('dotenv-flow') in that executable.

And the third thing is: If you agree with my second point (that dotenv-flow-cli is reasonable to install globally only), then it's better to have dotenv-flow as a direct dependency (not peer). It would be easier to install it just running npm -g dotenv-flow-cli.

And for sure I'm pleased that you want to transfer it to my username, but what is the reason? 😄

[falkenhawk]

Thanks for your input! I've renamed bin from dotenv to dotenv-flow to avoid conflicts with dotenv-cli.

Use case for local install: running defined scripts without an additional requirement of global install (esp. on CI) or having to add another .js wrapper just to run some command.

I've moved dotenv-flow from peer to direct dependencies anyway, I guess that won't hurt.

And for sure I'm pleased that you want to transfer it to my username, but what is the reason? 😄

oh I just thought, it might be easier for current or future users of dotenv-flow to discover this package if it's "next to" the mother package 😅 I can keep it under my name though no problem.

[kerimdzhanov]

Yeah, now I got it.

As for me, it seems that it doesn't give users easier discovering of the related packages. At least, almost nobody discovers the dotenv-flow-webpack package that I've created a year ago.

I think we need to create the "Related Packages" section in README.md, and list them all there.

[falkenhawk]

Package published: https://www.npmjs.com/package/dotenv-flow-cli