Closed falkenhawk closed 4 years ago
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.
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.
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? ð
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.
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.
Package published: https://www.npmjs.com/package/dotenv-flow-cli
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 withdotenv-flow k6 -- run load-tests.js
It would be a simple script, but will probably come with additional dependencies (
cross-spawn
andminimist
, ...and maybe, just maybedotenv-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)