Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parse args from config file #151

Closed
timoxley opened this issue May 29, 2013 · 10 comments
Closed

parse args from config file #151

timoxley opened this issue May 29, 2013 · 10 comments

Comments

@timoxley
Copy link

Can we bake something like the way mocha handles mocha.opts, straight into mocha? I often want to be able to choose from loading from config vs commandline vs overriding config with commandline args.

Perhaps:

.options('')// etc
.config('myapp.opts') 
.parse(process.argv) //etc

Perhaps the config file is overridable on the commandline with --config-file (though there's issues if anyone has defined this already as an option) or perhaps it can read from stdin

e.g.

$ cat /var/myconfig.opts | ./bin/myapp
@travisjeffery
Copy link

options:
  - flags: -a, --anchovies
    description: Add anchovies?

  - flags: -o, --onions
    description: Add onions?
    default: true

  - flags: -v, --olives
    description: Add olives? Sorry we only have black.
    default: black

  - flags: -s, --no-sauce
    description: Uh... okay

  - flags: -r, --crust <type>
    description: What kind of crust would you like?
    default: hand-tossed

  - flags: -c, --cheese [type]
    description: optionally specify the type of cheese
    default: mozzarella

here's a solution i was thinking of using yaml

@zhiyelee
Copy link
Collaborator

LGTM

@thethomaseffect
Copy link
Collaborator

This is an idea I had myself but I was going to implement it as a plugin, since it would add a new default flag to commander and potentially break existing code using -C or something similar. I should have a ton of time next month to work on v3 of commander so I can probably add this. However I'll probably use JSON rather than YAML since I think the trade offs (escaping, no first class dates) are worth it for how much easier it is to parse.

@travisjeffery
Copy link

mm i think the cleanliness of yaml is worth it alone. i definitely wouldn't want to read and write my example above in json. you could use our read-metadata module: https://github.com/segmentio/read-metadata which supports both yaml and json.

@rlidwka
Copy link
Contributor

rlidwka commented Nov 28, 2014

mm i think the cleanliness of yaml is worth it alone

Yes, it's definitely worth it.

It doesn't matter how difficult they are to parse (because there are existing yaml parsers already), and the syntax is just way better than json.

@zhiyelee
Copy link
Collaborator

@rlidwka +1 like js-yaml is already very mature

@shadowspawn
Copy link
Collaborator

This issue has not had any activity in over six months. It isn't likely to get acted on due to this report.

Feel free to open a new issue if it comes up again, with new information and renewed interest.

Thank you for your contributions.

@jakobrosenberg
Copy link

Hi @shadowspawn. Much appreciate all your hard work around here.

Do you know if there has been any changes in regards to config files since this was posted?

@shadowspawn
Copy link
Collaborator

Thanks @jakobrosenberg

I think the original poster was talking about supplying default values for options, but the subsequent conversation was more about adding new options from a control file. No changes related to config files in last year in either case.

@shadowspawn
Copy link
Collaborator

New open issue is #1584

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants