Skip to content
This repository has been archived by the owner on Aug 22, 2023. It is now read-only.

Allow a default to be specified for boolean flags #41

Merged
merged 1 commit into from
Oct 17, 2018
Merged

Allow a default to be specified for boolean flags #41

merged 1 commit into from
Oct 17, 2018

Conversation

rhwood
Copy link
Contributor

@rhwood rhwood commented Oct 17, 2018

This allows the use of boolean flag semantics where the default behavior for the application is as if --flag had been passed, and --no-flag is not the default behavior.

This allows the use of boolean flag symantecs where the default behavior for the application is as if `--flag` had been passed, and `--no-flag` is not the default behavoir.
@salesforce-cla
Copy link

Thanks for the contribution! Before we can merge this, we need @rhwood to sign the Salesforce.com Contributor License Agreement.

@codecov
Copy link

codecov bot commented Oct 17, 2018

Codecov Report

Merging #41 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master      #41   +/-   ##
=======================================
  Coverage   90.39%   90.39%           
=======================================
  Files          11       11           
  Lines         302      302           
  Branches       80       80           
=======================================
  Hits          273      273           
  Misses         10       10           
  Partials       19       19
Impacted Files Coverage Δ
src/flags.ts 100% <ø> (ø) ⬆️
src/parse.ts 91.24% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update af00006...798a5eb. Read the comment docs.

@jdx
Copy link
Contributor

jdx commented Oct 17, 2018

I touched on this in #34 but I'm not convinced this is very useful though. can you provide a real-world example of where you would want a default for a boolean flag?

@rhwood
Copy link
Contributor Author

rhwood commented Oct 17, 2018

I want to be able to make the (primary or only) flag be --no-flag on the CLI, but use flags.flag within the run method and have flags.flag be true if not specified by the user. Currently flags.flag is only true if --flag is specified, and false if not specified or if --no-flag is specified.

In my specific case, I have a tool that manages a server normally run as a daemon (i.e. detached from the console and parent process), but if a user wants to run the server as not a daemon, I want the user to use the --no-daemon flag, but I also want to be able use a function to not daemonize the server if DEBUG=* or TOOL_DEBUG=1 is set, unless the user explicitly passes --daemon.

What I would really like to be able to do is have this code when writing the flags:

daemon: flags.boolean({char: 'd', allowNo: true, default: () => {return !this.config.debug}})

so that when later checking if the server should be a daemon, I can simply use (flags.daemon) instead of using (flags.daemon || !(this.config.debug && flags.daemon !== undefined)) to determine if the process should be a daemon. I think that giving the boolean flag a contextual default is significantly simpler than checking that a combination of values is acceptable later.

@jdx
Copy link
Contributor

jdx commented Oct 17, 2018

ah I see, I think this makes sense. I appreciate the explanation.

At some point I'd like to hook this together with some sort of configuration utility to make this even more hands-off so you could do what you're doing with less code.

@jdx jdx merged commit f5053a5 into oclif:master Oct 17, 2018
oclif-bot added a commit that referenced this pull request Oct 17, 2018
# [3.7.0](v3.6.3...v3.7.0) (2018-10-17)

### Features

* Allow a default to be specified for boolean flags ([#41](#41)) ([f5053a5](f5053a5))
@oclif-bot
Copy link
Contributor

🎉 This PR is included in version 3.7.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

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

Successfully merging this pull request may close these issues.

3 participants