{
  "name": "dashdash",
  "description": "A light, featureful and explicit option parsing library.",
  "version": "1.14.1",
  "author": {
    "name": "Trent Mick",
    "email": "trentm@gmail.com",
    "url": "http://trentm.com"
  },
  "keywords": [
    "option",
    "parser",
    "parsing",
    "cli",
    "command",
    "args",
    "bash",
    "completion"
  ],
  "repository": {
    "type": "git",
    "url": "git://github.com/trentm/node-dashdash.git"
  },
  "main": "./lib/dashdash.js",
  "dependencies": {
    "assert-plus": "^1.0.0"
  },
  "devDependencies": {
    "nodeunit": "0.9.x"
  },
  "engines": {
    "node": ">=0.10"
  },
  "scripts": {
    "test": "nodeunit test/*.test.js"
  },
  "license": "MIT",
  "readme": "A light, featureful and explicit option parsing library for node.js.\n\n[Why another one? See below](#why). tl;dr: The others I've tried are one of\ntoo loosey goosey (not explicit), too big/too many deps, or ill specified.\nYMMV.\n\nFollow <a href=\"https://twitter.com/intent/user?screen_name=trentmick\" target=\"_blank\">@trentmick</a>\nfor updates to node-dashdash.\n\n# Install\n\n    npm install dashdash\n\n\n# Usage\n\n```javascript\nvar dashdash = require('dashdash');\n\n// Specify the options. Minimally `name` (or `names`) and `type`\n// must be given for each.\nvar options = [\n    {\n        // `names` or a single `name`. First element is the `opts.KEY`.\n        names: ['help', 'h'],\n        // See \"Option specs\" below for types.\n        type: 'bool',\n        help: 'Print this help and exit.'\n    }\n];\n\n// Shortcut form. As called it infers `process.argv`. See below for\n// the longer form to use methods like `.help()` on the Parser object.\nvar opts = dashdash.parse({options: options});\n\nconsole.log(\"opts:\", opts);\nconsole.log(\"args:\", opts._args);\n```\n\n\n# Longer Example\n\nA more realistic [starter script \"foo.js\"](./examples/foo.js) is as follows.\nThis also shows using `parser.help()` for formatted option help.\n\n```javascript\nvar dashdash = require('./lib/dashdash');\n\nvar options = [\n    {\n        name: 'version',\n        type: 'bool',\n        help: 'Print tool version and exit.'\n    },\n    {\n        names: ['help', 'h'],\n        type: 'bool',\n        help: 'Print this help and exit.'\n    },\n    {\n        names: ['verbose', 'v'],\n        type: 'arrayOfBool',\n        help: 'Verbose output. Use multiple times for more verbose.'\n    },\n    {\n        names: ['file', 'f'],\n        type: 'string',\n        help: 'File to process',\n        helpArg: 'FILE'\n    }\n];\n\nvar parser = dashdash.createParser({options: options});\ntry {\n    var opts = parser.parse(process.argv);\n} catch (e) {\n    console.error('foo: error: %s', e.message);\n    process.exit(1);\n}\n\nconsole.log(\"# opts:\", opts);\nconsole.log(\"# args:\", opts._args);\n\n// Use `parser.help()` for formatted options help.\nif (opts.help) {\n    var help = parser.help({includeEnv: true}).trimRight();\n    console.log('usage: node foo.js [OPTIONS]\\n'\n                + 'options:\\n'\n                + help);\n    process.exit(0);\n}\n\n// ...\n```\n\n\nSome example output from this script (foo.js):\n\n```\n$ node foo.js -h\n# opts: { help: true,\n  _order: [ { name: 'help', value: true, from: 'argv' } ],\n  _args: [] }\n# args: []\nusage: node foo.js [OPTIONS]\noptions:\n    --version             Print tool version and exit.\n    -h, --help            Print this help and exit.\n    -v, --verbose         Verbose output. Use multiple times for more verbose.\n    -f FILE, --file=FILE  File to process\n\n$ node foo.js -v\n# opts: { verbose: [ true ],\n  _order: [ { name: 'verbose', value: true, from: 'argv' } ],\n  _args: [] }\n# args: []\n\n$ node foo.js --version arg1\n# opts: { version: true,\n  _order: [ { name: 'version', value: true, from: 'argv' } ],\n  _args: [ 'arg1' ] }\n# args: [ 'arg1' ]\n\n$ node foo.js -f bar.txt\n# opts: { file: 'bar.txt',\n  _order: [ { name: 'file', value: 'bar.txt', from: 'argv' } ],\n  _args: [] }\n# args: []\n\n$ node foo.js -vvv --file=blah\n# opts: { verbose: [ true, true, true ],\n  file: 'blah',\n  _order:\n   [ { name: 'verbose', value: true, from: 'argv' },\n     { name: 'verbose', value: true, from: 'argv' },\n     { name: 'verbose', value: true, from: 'argv' },\n     { name: 'file', value: 'blah', from: 'argv' } ],\n  _args: [] }\n# args: []\n```\n\n\nSee the [\"examples\"](examples/) dir for a number of starter examples using\nsome of dashdash's features.\n\n\n# Environment variable integration\n\nIf you want to allow environment variables to specify options to your tool,\ndashdash makes this easy. We can change the 'verbose' option in the example\nabove to include an 'env' field:\n\n```javascript\n    {\n        names: ['verbose', 'v'],\n        type: 'arrayOfBool',\n        env: 'FOO_VERBOSE',         // <--- add this line\n        help: 'Verbose output. Use multiple times for more verbose.'\n    },\n```\n\nthen the **\"FOO_VERBOSE\" environment variable** can be used to set this\noption:\n\n```shell\n$ FOO_VERBOSE=1 node foo.js\n# opts: { verbose: [ true ],\n  _order: [ { name: 'verbose', value: true, from: 'env' } ],\n  _args: [] }\n# args: []\n```\n\nBoolean options will interpret the empty string as unset, '0' as false\nand anything else as true.\n\n```shell\n$ FOO_VERBOSE= node examples/foo.js                 # not set\n# opts: { _order: [], _args: [] }\n# args: []\n\n$ FOO_VERBOSE=0 node examples/foo.js                # '0' is false\n# opts: { verbose: [ false ],\n  _order: [ { key: 'verbose', value: false, from: 'env' } ],\n  _args: [] }\n# args: []\n\n$ FOO_VERBOSE=1 node examples/foo.js                # true\n# opts: { verbose: [ true ],\n  _order: [ { key: 'verbose', value: true, from: 'env' } ],\n  _args: [] }\n# args: []\n\n$ FOO_VERBOSE=boogabooga node examples/foo.js       # true\n# opts: { verbose: [ true ],\n  _order: [ { key: 'verbose', value: true, from: 'env' } ],\n  _args: [] }\n# args: []\n```\n\nNon-booleans can be used as well. Strings:\n\n```shell\n$ FOO_FILE=data.txt node examples/foo.js\n# opts: { file: 'data.txt',\n  _order: [ { key: 'file', value: 'data.txt', from: 'env' } ],\n  _args: [] }\n# args: []\n```\n\nNumbers:\n\n```shell\n$ FOO_TIMEOUT=5000 node examples/foo.js\n# opts: { timeout: 5000,\n  _order: [ { key: 'timeout', value: 5000, from: 'env' } ],\n  _args: [] }\n# args: []\n\n$ FOO_TIMEOUT=blarg node examples/foo.js\nfoo: error: arg for \"FOO_TIMEOUT\" is not a positive integer: \"blarg\"\n```\n\nWith the `includeEnv: true` config to `parser.help()` the environment\nvariable can also be included in **help output**:\n\n    usage: node foo.js [OPTIONS]\n    options:\n        --version             Print tool version and exit.\n        -h, --help            Print this help and exit.\n        -v, --verbose         Verbose output. Use multiple times for more verbose.\n                              Environment: FOO_VERBOSE=1\n        -f FILE, --file=FILE  File to process\n\n\n# Bash completion\n\nDashdash provides a simple way to create a Bash completion file that you\ncan place in your \"bash_completion.d\" directory -- sometimes that is\n\"/usr/local/etc/bash_completion.d/\"). Features:\n\n- Support for short and long opts\n- Support for knowing which options take arguments\n- Support for subcommands (e.g. 'git log <TAB>' to show just options for the\n  log subcommand). See\n  [node-cmdln](https://github.com/trentm/node-cmdln#bash-completion) for\n  how to integrate that.\n- Does the right thing with \"--\" to stop options.\n- Custom optarg and arg types for custom completions.\n\nDashdash will return bash completion file content given a parser instance:\n\n    var parser = dashdash.createParser({options: options});\n    console.log( parser.bashCompletion({name: 'mycli'}) );\n\nor directly from a `options` array of options specs:\n\n    var code = dashdash.bashCompletionFromOptions({\n        name: 'mycli',\n        options: OPTIONS\n    });\n\nWrite that content to \"/usr/local/etc/bash_completion.d/mycli\" and you will\nhave Bash completions for `mycli`. Alternatively you can write it to\nany file (e.g. \"~/.bashrc\") and source it.\n\nYou could add a `--completion` hidden option to your tool that emits the\ncompletion content and document for your users to call that to install\nBash completions.\n\nSee [examples/ddcompletion.js](examples/ddcompletion.js) for a complete\nexample, including how one can define bash functions for completion of custom\noption types. Also see [node-cmdln](https://github.com/trentm/node-cmdln) for\nhow it uses this for Bash completion for full multi-subcommand tools.\n\n- TODO: document specExtra\n- TODO: document includeHidden\n- TODO: document custom types, `function complete\\_FOO` guide, completionType\n- TODO: document argtypes\n\n\n# Parser config\n\nParser construction (i.e. `dashdash.createParser(CONFIG)`) takes the\nfollowing fields:\n\n- `options` (Array of option specs). Required. See the\n  [Option specs](#option-specs) section below.\n\n- `interspersed` (Boolean). Optional. Default is true. If true this allows\n  interspersed arguments and options. I.e.:\n\n        node ./tool.js -v arg1 arg2 -h   # '-h' is after interspersed args\n\n  Set it to false to have '-h' **not** get parsed as an option in the above\n  example.\n\n- `allowUnknown` (Boolean).  Optional.  Default is false.  If false, this causes\n  unknown arguments to throw an error.  I.e.:\n\n        node ./tool.js -v arg1 --afe8asefksjefhas\n\n  Set it to true to treat the unknown option as a positional\n  argument.\n\n  **Caveat**: When a shortopt group, such as `-xaz` contains a mix of\n  known and unknown options, the *entire* group is passed through\n  unmolested as a positional argument.\n\n  Consider if you have a known short option `-a`, and parse the\n  following command line:\n\n        node ./tool.js -xaz\n\n  where `-x` and `-z` are unknown.  There are multiple ways to\n  interpret this:\n\n    1. `-x` takes a value: `{x: 'az'}`\n    2. `-x` and `-z` are both booleans: `{x:true,a:true,z:true}`\n\n  Since dashdash does not know what `-x` and `-z` are, it can't know\n  if you'd prefer to receive `{a:true,_args:['-x','-z']}` or\n  `{x:'az'}`, or `{_args:['-xaz']}`. Leaving the positional arg unprocessed\n  is the easiest mistake for the user to recover from.\n\n\n# Option specs\n\nExample using all fields (required fields are noted):\n\n```javascript\n{\n    names: ['file', 'f'],       // Required (one of `names` or `name`).\n    type: 'string',             // Required.\n    completionType: 'filename',\n    env: 'MYTOOL_FILE',\n    help: 'Config file to load before running \"mytool\"',\n    helpArg: 'PATH',\n    helpWrap: false,\n    default: path.resolve(process.env.HOME, '.mytoolrc')\n}\n```\n\nEach option spec in the `options` array must/can have the following fields:\n\n- `name` (String) or `names` (Array). Required. These give the option name\n  and aliases. The first name (if more than one given) is the key for the\n  parsed `opts` object.\n\n- `type` (String). Required. One of:\n\n    - bool\n    - string\n    - number\n    - integer\n    - positiveInteger\n    - date (epoch seconds, e.g. 1396031701, or ISO 8601 format\n      `YYYY-MM-DD[THH:MM:SS[.sss][Z]]`, e.g. \"2014-03-28T18:35:01.489Z\")\n    - arrayOfBool\n    - arrayOfString\n    - arrayOfNumber\n    - arrayOfInteger\n    - arrayOfPositiveInteger\n    - arrayOfDate\n\n  FWIW, these names attempt to match with asserts on\n  [assert-plus](https://github.com/mcavage/node-assert-plus).\n  You can add your own custom option types with `dashdash.addOptionType`.\n  See below.\n\n- `completionType` (String). Optional. This is used for [Bash\n  completion](#bash-completion) for an option argument. If not specified,\n  then the value of `type` is used. Any string may be specified, but only the\n  following values have meaning:\n\n    - `none`: Provide no completions.\n    - `file`: Bash's default completion (i.e. `complete -o default`), which\n      includes filenames.\n    - *Any string FOO for which a `function complete_FOO` Bash function is\n      defined.* This is for custom completions for a given tool. Typically\n      these custom functions are provided in the `specExtra` argument to\n      `dashdash.bashCompletionFromOptions()`. See\n      [\"examples/ddcompletion.js\"](examples/ddcompletion.js) for an example.\n\n- `env` (String or Array of String). Optional. An environment variable name\n  (or names) that can be used as a fallback for this option. For example,\n  given a \"foo.js\" like this:\n\n        var options = [{names: ['dry-run', 'n'], env: 'FOO_DRY_RUN'}];\n        var opts = dashdash.parse({options: options});\n\n  Both `node foo.js --dry-run` and `FOO_DRY_RUN=1 node foo.js` would result\n  in `opts.dry_run = true`.\n\n  An environment variable is only used as a fallback, i.e. it is ignored if\n  the associated option is given in `argv`.\n\n- `help` (String). Optional. Used for `parser.help()` output.\n\n- `helpArg` (String). Optional. Used in help output as the placeholder for\n  the option argument, e.g. the \"PATH\" in:\n\n        ...\n        -f PATH, --file=PATH    File to process\n        ...\n\n- `helpWrap` (Boolean). Optional, default true. Set this to `false` to have\n  that option's `help` *not* be text wrapped in `<parser>.help()` output.\n\n- `default`. Optional. A default value used for this option, if the\n  option isn't specified in argv.\n\n- `hidden` (Boolean). Optional, default false. If true, help output will not\n  include this option. See also the `includeHidden` option to\n  `bashCompletionFromOptions()` for [Bash completion](#bash-completion).\n\n\n# Option group headings\n\nYou can add headings between option specs in the `options` array.  To do so,\nsimply add an object with only a `group` property -- the string to print as\nthe heading for the subsequent options in the array.  For example:\n\n```javascript\nvar options = [\n    {\n        group: 'Armament Options'\n    },\n    {\n        names: [ 'weapon', 'w' ],\n        type: 'string'\n    },\n    {\n        group: 'General Options'\n    },\n    {\n        names: [ 'help', 'h' ],\n        type: 'bool'\n    }\n];\n...\n```\n\nNote: You can use an empty string, `{group: ''}`, to get a blank line in help\noutput between groups of options.\n\n\n# Help config\n\nThe `parser.help(...)` function is configurable as follows:\n\n        Options:\n          Armament Options:\n        ^^  -w WEAPON, --weapon=WEAPON  Weapon with which to crush. One of: |\n       /                                sword, spear, maul                  |\n      /   General Options:                                                  |\n     /      -h, --help                  Print this help and exit.           |\n    /   ^^^^                            ^                                   |\n    \\       `-- indent                   `-- helpCol              maxCol ---'\n     `-- headingIndent\n\n- `indent` (Number or String). Default 4. Set to a number (for that many\n  spaces) or a string for the literal indent.\n- `headingIndent` (Number or String). Default half length of `indent`. Set to\n  a number (for that many spaces) or a string for the literal indent. This\n  indent applies to group heading lines, between normal option lines.\n- `nameSort` (String). Default is 'length'. By default the names are\n  sorted to put the short opts first (i.e. '-h, --help' preferred\n  to '--help, -h'). Set to 'none' to not do this sorting.\n- `maxCol` (Number). Default 80. Note that reflow is just done on whitespace\n  so a long token in the option help can overflow maxCol.\n- `helpCol` (Number). If not set a reasonable value will be determined\n  between `minHelpCol` and `maxHelpCol`.\n- `minHelpCol` (Number). Default 20.\n- `maxHelpCol` (Number). Default 40.\n- `helpWrap` (Boolean). Default true. Set to `false` to have option `help`\n  strings *not* be textwrapped to the helpCol..maxCol range.\n- `includeEnv` (Boolean). Default false. If the option has associated\n  environment variables (via the `env` option spec attribute), then\n  append mentioned of those envvars to the help string.\n- `includeDefault` (Boolean). Default false. If the option has a default value\n  (via the `default` option spec attribute, or a default on the option's type),\n  then a \"Default: VALUE\" string will be appended to the help string.\n\n\n# Custom option types\n\nDashdash includes a good starter set of option types that it will parse for\nyou. However, you can add your own via:\n\n    var dashdash = require('dashdash');\n    dashdash.addOptionType({\n        name: '...',\n        takesArg: true,\n        helpArg: '...',\n        parseArg: function (option, optstr, arg) {\n            ...\n        },\n        array: false,  // optional\n        arrayFlatten: false,  // optional\n        default: ...,   // optional\n        completionType: ...  // optional\n    });\n\nFor example, a simple option type that accepts 'yes', 'y', 'no' or 'n' as\na boolean argument would look like:\n\n    var dashdash = require('dashdash');\n\n    function parseYesNo(option, optstr, arg) {\n        var argLower = arg.toLowerCase()\n        if (~['yes', 'y'].indexOf(argLower)) {\n            return true;\n        } else if (~['no', 'n'].indexOf(argLower)) {\n            return false;\n        } else {\n            throw new Error(format(\n                'arg for \"%s\" is not \"yes\" or \"no\": \"%s\"',\n                optstr, arg));\n        }\n    }\n\n    dashdash.addOptionType({\n        name: 'yesno'\n        takesArg: true,\n        helpArg: '<yes|no>',\n        parseArg: parseYesNo\n    });\n\n    var options = {\n        {names: ['answer', 'a'], type: 'yesno'}\n    };\n    var opts = dashdash.parse({options: options});\n\nSee \"examples/custom-option-\\*.js\" for other examples.\nSee the `addOptionType` block comment in \"lib/dashdash.js\" for more details.\nPlease let me know [with an\nissue](https://github.com/trentm/node-dashdash/issues/new) if you write a\ngenerally useful one.\n\n\n\n# Why\n\nWhy another node.js option parsing lib?\n\n- `nopt` really is just for \"tools like npm\". Implicit opts (e.g. '--no-foo'\n  works for every '--foo'). Can't disable abbreviated opts. Can't do multiple\n  usages of same opt, e.g. '-vvv' (I think). Can't do grouped short opts.\n\n- `optimist` has surprise interpretation of options (at least to me).\n  Implicit opts mean ambiguities and poor error handling for fat-fingering.\n  `process.exit` calls makes it hard to use as a libary.\n\n- `optparse` Incomplete docs. Is this an attempted clone of Python's `optparse`.\n  Not clear. Some divergence. `parser.on(\"name\", ...)` API is weird.\n\n- `argparse` Dep on underscore. No thanks just for option processing.\n  `find lib | wc -l` -> `26`. Overkill.\n  Argparse is a bit different anyway. Not sure I want that.\n\n- `posix-getopt` No type validation. Though that isn't a killer. AFAIK can't\n  have a long opt without a short alias. I.e. no `getopt_long` semantics.\n  Also, no whizbang features like generated help output.\n\n- [\"commander.js\"](https://github.com/visionmedia/commander.js): I wrote\n  [a critique](http://trentm.com/2014/01/a-critique-of-commander-for-nodejs.html)\n  a while back. It seems fine, but last I checked had\n  [an outstanding bug](https://github.com/visionmedia/commander.js/pull/121)\n  that would prevent me from using it.\n\n\n# License\n\nMIT. See LICENSE.txt.\n",
  "readmeFilename": "README.md",
  "bugs": {
    "url": "https://github.com/trentm/node-dashdash/issues"
  },
  "homepage": "https://github.com/trentm/node-dashdash",
  "_id": "dashdash@1.14.1",
  "_shasum": "853cfa0f7cbe2fed5de20326b8dd581035f6e2f0",
  "_from": "dashdash@^1.12.0",
  "_resolved": "https://registry.npmjs.org/dashdash/-/dashdash-1.14.1.tgz"
}
