(nothing yet)
$ triton -v -p test2 package get <TAB> # before ##-no -tritonpackage- completions-## $ triton -v -p test2 package get <TAB> # after ##-no-completion- -results-##
synopsisFromOpt(<option spec>)
function. This will be used by node-cmdln to put together a synopsis of options for a command. Some examples:> synopsisFromOpt({names: ['help', 'h'], type: 'bool'}); '[ --help | -h ]' > synopsisFromOpt({name: 'file', type: 'string', helpArg: 'FILE'}); '[ --file=FILE ]'
bashCompletionSpecFromOptions
breaks on an options array with an empty-string group.Update assert-plus dep to 1.x to get recent fixes (particularly for assert.optional*
).
Drop testing (and official support in packages.json#engines) for node 0.8.x. Add testing against node 5.x and 4.x with make testall
.
[pull #16] Change the positiveInteger
type to NOT accept zero (0). For those who might need the old behaviour, see "examples/custom-option-intGteZero.js". (By Dave Pacheco.)
Bash completion: Add argtypes
to specify the types of positional args. E.g. this would allow you to have an ssh
command with argtypes = ['host', 'cmd']
for bash completion. You then have to provide Bash functions to handle completing those types via the specExtra
arg. See "examples/ddcompletion.js" for an example.
Bash completion: Tweak so that options or only offered as completions when there is a leading '-'. E.g. mytool <TAB>
does NOT offer options, mytool -<TAB>
does. Without this, a tool with options would never be able to fallback to Bash's "default" completion. For example ls <TAB>
wouldn't result in filename completion. Now it will.
Bash completion: A workaround for not being able to explicitly have no completion results. Because dashdash's completion uses complete -o default
, we fallback to Bash's "default" completion (typically for filename completion). Before this change, an attempt to explicitly say "there are no completions that match" would unintentionally trigger filename completion. Instead as a workaround we return:
$ ddcompletion --none <TAB> # the 'none' argtype ##-no completions-## $ ddcompletion # a custom 'fruit' argtype apple banana orange $ ddcompletion z ##-no -fruit- completions-##
This is a bit of a hack, but IMO a better experience than the surprise of matching a local filename beginning with 'z', which isn't, in this case, a "fruit".
<option spec>.completionType
. Add includeHidden
option to bashCompletionSpecFromOptions()
. Add support for dealing with hidden subcmds.arrayFlatten
boolean option to dashdash.addOptionType
used for custom option types. This allows one to create an arrayOf...
option type where each usage of the option can return multiple results. For example:node mytool.js --foo a,b --foo cWe could define an option type for
--foo
such that opts.foo = ['a', 'b', 'c']
. See "examples/custom-option-arrayOfCommaSepString.js" for an example.npm
won't let me drop the README.md. :)includeDefault
in help config (similar to includeEnv
) to have a note of an option's default value, if any, in help output.addOptionType
can specify a "default" value. See "examples/custom-option-fruit.js".hidden: true
in an option spec to have help output exclude this option.tail
with a -f
boolean option and a -n
option that takes a number argument. This should parse:tail -fn5Before this change, that would not parse correctly. It is suspected that this was introduced in version 1.4.0 (with commit 656fa8bc71c372ebddad0a7026bd71611e2ec99a).
Known issues: #8
Exclude 'tools/' dir in packages published to npm.
Known issues: #8
Support an option group empty string value:
... { group: '' }, ...
to render as a blank line in option help. This can help separate loosely related sets of options without resorting to a title for option groups.
Known issues: #8
[pull #7] Support for <parser>.help({helpWrap: false, ...})
option to be able to fully control the formatting for option help (by Patrick Mooney) helpWrap: false
can also be set on individual options in the option objects, e.g.:
var options = [ { names: ['foo'], type: 'string', helpWrap: false, help: 'long help with\n newlines' + '\n spaces\n and such\nwill render correctly' }, ... ];
Known issues: #8
[pull #6] Support headings between groups of options (by Joshua M. Clulow) so that this code:
var options = [ { group: 'Armament Options' }, { names: [ 'weapon', 'w' ], type: 'string' }, { group: 'General Options' }, { names: [ 'help', 'h' ], type: 'bool' } ]; ...
will give you this help output:
... Armament Options: -w, --weapon General Options: -h, --help ...
Known issues: #8
Add support for adding custom option types. "examples/custom-option-duration.js" shows an example adding a "duration" option type.
$ node custom-option-duration.js -t 1h duration: 3600000 ms $ node custom-option-duration.js -t 1s duration: 1000 ms $ node custom-option-duration.js -t 5d duration: 432000000 ms $ node custom-option-duration.js -t bogus custom-option-duration.js: error: arg for "-t" is not a valid duration: "bogus"
A custom option type is added via:
var dashdash = require('dashdash'); dashdash.addOptionType({ name: '...', takesArg: true, helpArg: '...', parseArg: function (option, optstr, arg) { ... } });
[issue #4] Add date
and arrayOfDate
option types. They accept these date formats: epoch second times (e.g. 1396031701) and ISO 8601 format: YYYY-MM-DD[THH:MM:SS[.sss][Z]]
(e.g. "2014-03-28", "2014-03-28T18:35:01.489Z"). See "examples/date.js" for an example usage.
$ node examples/date.js -s 2014-01-01 -e $(date +%s) start at 2014-01-01T00:00:00.000Z end at 2014-03-29T04:26:18.000Z
Known issues: #8
[pull #2, pull #3] Add a allowUnknown: true
option on createParser
to allow unknown options to be passed through as opts._args
instead of parsing throwing an exception (by https://github.com/isaacs).
See 'allowUnknown' in the README for a subtle caveat.
env
and default
didn't work exactly correctly. If default: false
then all was fine (by luck). However, if you had an option like this:options: [ { names: ['verbose', 'v'], env: 'FOO_VERBOSE', 'default': true, // <--- this type: 'bool' } ],wanted
FOO_VERBOSE=0
to make the option false, then you need the fix in this version of dashdash.default
and env
would never take a value from the environment variable. E.g. FOO_FILE
would never work here:options: [ { names: ['file', 'f'], env: 'FOO_FILE', 'default': 'default.file', type: 'string' } ],
$ FOO_VERBOSE=0 node examples/foo.js # opts: { verbose: [ false ], _order: [ { key: 'verbose', value: false, from: 'env' } ], _args: [] } # args: []
parse.help({includeEnv: true, ...})
handling to ensure that an option with an env
but no help
still has the "Environment: ..." output. E.g.:{ names: ['foo'], type: 'string', env: 'FOO' } ... --foo=ARG Environment: FOO=ARG
opts
object returned from <parser>.parse()
for convenience. Currently this is just s/-/_/g
, e.g. '--dry-run' -> opts.dry_run
. This allow one to use hyphen in option names (common) but not have to do silly things like opt["dry-run"]
to access the parsed results.Environment variable integration. Envvars can be associated with an option, then option processing will fallback to using that envvar if defined and if the option isn't specified in argv. See the "Environment variable integration" section in the README.
Change the <parser>.parse()
signature to take a single object with keys for arguments. The old signature is still supported.
dashdash.createParser(CONFIG)
alternative to new dashdash.Parser(CONFIG)
a la many node-land APIs.
Add "positiveInteger" and "arrayOfPositiveInteger" option types that only accept positive integers.
Add "integer" and "arrayOfInteger" option types that accepts only integers. Note that, for better or worse, these do NOT accept: "0x42" (hex), "1e2" (with exponent) or "1.", "3.0" (floats).
First release.