\n\n\n\n \n\n## About\n\n<neodoc> is a revised implementation of the [docopt\nlanguage][docopt-orig] for node. In brief, it offers a unique way to author\ncommand lines by writing the command line's help text first and then deriving\na matching parser from it, which can then be applied to user input. The\nadvantages are numerous:\n\n* **No boilerplate** - just write your help-text\n* Full control over **beautiful, hand-crafted help texts**\n* Documentation comes first - **hence your users come first**\n* Documentation is always right - **your help-text is _necessarily_ correct**\n* Version-controlled help-text - **the help-text becomes a regular part of your codebase**\n\nThis implementation features **error reporting**, both for users and developers,\nreading values from **environment variables**, type coercion and much more. For\nan (in-)comprehensive comparison to the original, [click\nhere](#deviations-from-the-original). To take neodoc for a ride, [click\nhere][playground].\n\n> **_A note to potential adopters and contributors:_** Neodoc is divided into two\ndistinct parts — parsing the specification and parsing the argv, given the\nspecificiation. Theoretically, the origin of the specification does not matter\nand the argv parser could be used standalone as it offers a more \"correct\" parse\nthan most cli parsers out there, since it parses the input guided by the\nspecification, rather than parsing the input and then matching it to the\nspecification. See the \"Features\" section below. If neodoc finds adoption, I\nwould not be surprised to see projects mimicking a yargs-like interface that use\nthe neodoc parser, even though it somewhat defies the original idea of docopt.\n\n## Features ##\n\n* Derive command line interface from help text\n* Helpful error messages for both developers and users\n* _Options-first_ parsing to compose large programs (see git example)\n* Fallback to alternate values: `Argv -> Environment -> Defaults -> Empty`\n* Convenient, concise and widely accepted POSIX-style syntax\n * `-f[=ARG], --foo[=ARG]` options\n * ``, `ARG` positionals\n * `clone`, `pull`, etc. commands\n * `[]` optional groupings\n * `(])` required groupings\n * `[-f ARG]` POSIX-style flags\n * `-f[=ARG]...` repeating elements\n * `--` end of options separator\n * `-` stdin marker\n * 99% compatible with a typical `git --help` output\n * Full overview of the language →\n* Stop parsing at any option and collect successive input as the argument to\n that option. Similar to `--` but for named options (and their aliases).\n* Specification parsing (help-text parsing) is separated from argv parsing\n and can be used for other projects outside of neodoc. _Work is underway to\n make the argv parser usable from JS as well_.\n* Count repeated flags\n* Parses values into primitive JS types (bool, string, number)\n* Correct and smart argument parsing. For example, neodoc has absolutely no\n problem parsing this input: `tar -xvzfsome-dir/some-file`, given a\n specification of: `usage: tar [-xvzf FILE]` while other parses would not know\n that the option stack ends at `-f` and falsly parse this as `-x -v -z -f -s -o\n -m -e=-dir/some-file` at best.\n\n\n## Installation ##\n\n```sh\nnpm install --save neodoc\n```\n\n## Usage ##\n\n### neodoc.run(help | spec, opts)\n\nParse and apply the given docopt help text. Alternatively, pass the output of\n`neodoc.parse`. If no options are provided, apply it to `process.argv` and\n`process.env`. The result is a mapping of key -> value, where the key is the\ncanonical form of the option and its alias, if available.\n\nOptions:\n\n* `opts.dontExit` - Do not exit upon error or when parsing `--help` or\n `--version`. Instead throw and error / return the value.\n* `opts.env` - Override `process.env`\n* `opts.argv` - Override `process.argv`\n* `opts.optionsFirst` - Parse until the first `command` or ``\n argument, then collect the rest into an array, given the help indicates\n another, repeatable, positional argument, e.g. : `[options] \n [...]`\n* `opts.smartOptions` - Enable parsing groups that \"look like\" options as\n options. For example: `[-f ARG...]` means `[-f=ARG...]`\n* `opts.stopAt` - Stop parsing at the given options, i.e. `[ -n ]`. It's value\n will be the rest of argv.\n* `opts.requireFlags` - Require flags be present in the input. In neodoc, flags\n are optional by default and can be omitted. This option forces the user to\n pass flags explicitly, failing the parse otherwise.\n* `opts.laxPlacement` - Relax placement rules. Positionals and commands are no\n longer solid anchors. The order amongs them, however, remains fixed. This\n implies that options can appear anywhere.\n* `opts.versionFlags` - An array of flags that trigger the special version\n behavior: Print the program version and exit with code 0.\n* `opts.version` - The version to print for the special version behavior.\n Defaults to finding the version of the nearest package.json file, relative\n to the executing main module. Note that disk IO is only performed if\n `opts.versionFlags` is non-empty and `opts.version` is not set.\n* `opts.helpFlags` - An array of flags that trigger the special help\n behavior: Print the full program help text and exit with code 0.\n* `opts.repeatableOptions` - Allow options to be repeated even if the spec does\n not explicitly allow this. This \"loosens\" up the parser to accept more input\n and makes for a more intuitive command line. _Please note:_ repeatability\n is still subject to chunking (use `opts.laxPlacement` to relax this further).\n* `opts.transforms.presolve` - an array of functions to be called prior to\n \"solving\" the input. This function takes the spec as it's only parameter.\n At this point, the spec is mostly untouched by neodoc with the exception of\n smart-options which runs as a fixed transform prior to user-provided callbacks\n if `smart-options` is true. Transforms that need to be aware of option stacks\n and `[...-options]` references should run here as this information is lost\n during the solving transforms.\n* `opts.transforms.postsolve` - an array of functions to be called after\n \"solving\" the input, just prior to passing the spec to the arg-parser. This\n function takes the spec as it's only parameter. At this point, the spec has\n been fully solved, expanded and canonicalised.\n* `opts.allowUnknown` - Collect unknown options under a special key `?` instead\n of failing. Useful to send an unknown subset of options to another program.\n\nFor example:\n\n```javascript\n#!/usr/bin/env node\n\nconst neodoc = require('neodoc');\n\nconst args = neodoc.run(`\nusage: git [--version] [--help] [-C ] [-c ]\n [--exec-path[=]] [--html-path] [--man-path] [--info-path]\n [-p|--paginate|--no-pager] [--no-replace-objects] [--bare]\n [--git-dir=] [--work-tree=] [--namespace=]\n [...]\n`, { optionsFirst: true, smartOptions: true });\n\nif (args[''] === 'remote') {\n const remoteArgs = neodoc.run(`\n usage:\n git remote [-v | --verbose]\n git remote add [-t ] [-m ] [-f] [--tags|--no-tags]\n [--mirror=] \n git remote rename \n git remote remove \n git remote [-v | --verbose] show [-n] ...\n git remote prune [-n | --dry-run] ...\n git remote [-v | --verbose] update [-p | --prune] [( | )...]\n `, { argv: ['remote'].concat(args['']), smartOptions: true })\n\n // ...\n} else { /* ... */ }\n```\n\nSee the examples folder for a more sophisticated version of the above example.\n\n### neodoc.parse(help, opts)\n\nParse the docopt text and derive the specification along with some meta information.\nThe specification is the canonical representation of the CLI as described by it's\nhelp text and can be used for building parsers etc. The output is a plain JS object\nand can be serialized. The output can further be passed to `neodoc.run`. This avoids\nneodoc having to parse and solve the original help text again, since parsing JSON\nis a order of magnitude faster to parse.\n\n## Language overview and terminology\n\nThis section gives an overview over the neodoc cli **specification** language.\nKeywords are highlighted.\n\nThe over-arching format could be described as follows:\n\n```sh\nUsage: [...] [| [...]]\n[ [or:] [...] [| [...]]\n]*\n\n[options:\n [ []\n ]*\n]*\n```\n\nWhere `` may be any of the arguments described in the following\nsubsections.\n\nA full example:\n\n```sh\nusage: git fetch [options] [ [...]]\n or: git fetch [options] \n or: git fetch --multiple [options] [( | )...]\n or: git fetch --all [options]\n\noptions:\n -v, --verbose be more verbose\n -q, --quiet be more quiet\n --all fetch from all remotes\n -a, --append append to .git/FETCH_HEAD instead of overwriting\n --upload-pack path to upload pack on remote end\n -f, --force force overwrite of local branch\n -m, --multiple fetch from multiple remotes\n -t, --tags fetch all tags and associated objects\n [...]\n```\n\n### 1. Arguments\n\nAt the heart of the language are command line arguments. There are three\nfundamental types of arguments: `options`, `positional` arguments and\n`commands`. Options are arguments that start with either a single or a double\ndash ('-'), commands are literal matches of a certain string and positionals\nconstitute everything else. Read on below for more detail on each argument\ntype.\n\n#### 1.1. Options\n\nOptions are those arguments that start with either one or two dashes. They are\nreferred to as \"short\" and \"long\" options respectively throughout this document\nand the source code of neodoc.\n\nOptions may take an potentially optional option-argument. Options that do not\nare referred to as flags. Options that do specify an option-argument but declare\nit as being optional may behave as flags if an argument could not be consumed at\nruntime.\n\nThe following is true for all options:\n\n* Options may take an optional \"option-argument\"\n* Options may be repeated using `...`\n* Adjacent options are not fixed in position: `-a -b` is equivalent to `-b -a`.\n Likewise, `-ab` is equivalent to `-ba`. This also holds true for options that\n take option-arguments.\n* Options that are repeated collect values into an array\n* Flags that are repeated count the number of occurrences\n* Flags that are not repeated simply yield `true` if present\n* Flags and options with an optional option-argument can always be omitted from\n the input. They simply won't yield anything in the output value mapping.\n* Options may alias a short (one-character) form with a long form, e.g.: `-v,\n --verbose`\n* Options that take an argument can specify a `[default: ]` in the option\n section as fallback.\n* Options that take an argument can specify a `[env: ]` in the option\n section as fallback.\n\n##### 1.1.1. Long options\n\n**Long options** are lead by two dashes and may take an potentially optional\noption-argument.\\\nFor example:\n\n* `--long ` the option-argument is loosely bound\n* `--long ` the option-argument is loosely bound and optional. ([#55][issue-55])\n* `--long=` the option-argument is explicitly bound\n* `--long[=]` the option-argument is explicitly bound an optional\n* `[--long ]` the option-argument is explicitly bound via the `smart-options` setting\n* `[--long []]` the option-argument is loosely bound via the `smart-options` setting and optional\n\nNote that all of the above forms could be followed by a `...`, indicating that\nthis option may appear one or more times. The repeated occurrence does not\nnecessarily need to be adjacent to the previous match. Repeated occurrences\nare collected into an array or into a count if the option qualifies as a flag.\n\nNote that successive dashes are allowed: `--very-long-option`.\n\n##### 1.1.2. Short options\n\n**Short options** are lead by one dash and may take an potentially optional\noption-argument. A short option is a one character identifier, but can be\n\"stacked\".\n\nFor example:\n\n* `-a ` the option-argument is loosely bound to `-a`\n* `-a=` the option-argument is explicitly bound to `-a`\n* `-a` the option-argument is explicitly bound to `-a`\n* `-aARG` the option-argument is **loosely** bound to `-a`\n* `-a []` the option-argument is loosely bound to `-a`. ([#55][issue-55])\n* `-a=` the option-argument is explicitly bound to `-a`\n* `-a[=]` the option-argument is explicitly bound to `-a` an optional\n* `[-a ]` the option-argument is explicitly bound to `-a` via the `smart-options` setting\n* `[-a []]` the option-argument is loosely bound to `-a` via the `smart-options` setting and optional\n\nNote, however that only the last option in the \"option stack\" may actually bind\nan argument:\n\n* `-abc` is equivalent to `-a -b -c`\n* `-abc ` is equivalent to `-a -b -c `\n* `-abc=` is equivalent to `-a -b -c=`\n* `-abc[=]` is equivalent to `-a -b -c=`\n\n...essentially nothing changes when options are stacked. Key is that only the\nlast option in the stack may bind and consume arguments.\n\nAgain, note that all of the above forms could be followed by a `...`, indicating\nthat this option may appear one or more times. It is important to note that the\nrepeatability is assigned to **all** options in the stack! Repeated occurrences\nare collected into an array or into a count if the option qualifies as a flag\n(hence for all but the last options in the stack).\n\n##### 1.1.3. Option-arguments\n\n**Option-arguments** are arguments bound to options. If an option is said to\ntake an option argument that is not optional, any attempt to match an option\nwithout the argument will result in an immediate parse error. Should an\noption-argument be declared optional and not matched during parsing, it may be\ntreated as a flag and be substituted.\n\n###### 1.1.3.1. Option-argument bindings\n\n* \"loose\" binding: the option-argument is in adjacent position, but\n needs to be confirmed in the 'options' section. Should\n confirmation not take place, the adjacent argument is treated as a\n positional.\n* \"explicit\" binding: the option-argument is explicitly bound due to\n a lack of whitespace, an equal sign or through 'smart-options'.\n\n##### 1.1.4 The option secion\n\nThe option section gives a chance to add more information about options, such\nas their default value, their alias or their backing environment variable.\nFurthermore, options appearing in the option section may also indicate if the\noption is supposed to be repeatable or not. There is more information on this\ntopic in section \"1.7 - References - [options]\".\n\n* An alias is assigned via `-v, --verbose`\n* A default value is assigned via `[default: value]`\n* An environment variable is assigned via `[env: MY_KEY]`\n\nFor example:\n\n```\noptions:\n -f, --foo BAR This is foo bar. [env: FOO_BAR] [default: 123]\n```\n\nThe text is pretty flexible and can be arranged as the author pleases. For\nexample:\n\n```\noptions:\n -f, --foo BAR...\n This is foo bar.\n [env: FOO_BAR] [default: 123]\n```\n\n#### 1.2. Positionals\n\n**Positionals** are arguments that do not lead with any dashes. The position\nof their occurrence matters and options are \"bounded\" by them in that an option\ndeclared before an positional argument may not occur after that positional. ([#24][issue-24])\nPositional arguments are distinguished from _commands_ by being either enclosed\nin angled brackets or being all upper case.\n\nFor example:\n* `` is a positional element named ``\n* `ARG` is a positional element named `ARG`\n* `[]` is an optional positional element named ``\n* `[ARG]` is an optional positional element named `ARG`\n* `[]...` is an optional positional element named `` that repeats\n* `...` is a positional element named `` that repeats\n\nPositional arguments either yield a single value if not repeated or an array of\nvalues if repeated. Note that contrary to options, repetition must occur\ndirectly adjacent to the previous match. ([#24][issue-24])\n\n#### 1.3. Commands\n\n**Commands** are a specialized form of positionals that require to be matched\nliterally, including casing. All other rules that apply to positionals apply to\ncommands. They yield a boolean indicating their presence or a count indicating\nthe number of their occurrences if repeated.\n\nFor example:\n* `command` must be matched with input \"command\" on argv\n* `command...` must be matched on ore more times with input \"command\" on argv\n\n#### 1.4. EOA - end-of-arguments\n\nThe **EOA (end-of-arguments)** is understood as the separator between known and\nunknown arguments. The eoa is typically `--` but any option can become one by\nusing the 'stop-at' setting.\\o\n\nFor example:\n* `--`\n* `-- ARGS`\n* `-- ARGS...`\n* `[-- ARGS...]`\n* `[-- [ARGS...]]`\n* ...and so on — they all have the same meaning.\n\n#### 1.5. Stdin marker\n\nThe **stdin** flag is a special, unnamed short-option: `-`. It's presence\nindicates that the program should be reading from standard input.\n\n#### 1.6. Groups\n\nGroups are the only recursive argument type. Groups describe one or more\nmutually exclusive sets of arguments called \"branches\". At least one branch\nneeds to yield a successful parse for the group to succeed.\n\nFor example:\n\n* `(foo | bar qux)` means either match command `foo` or command `bar`\n directly followed by command `qux`.\n* `[foo | bar qux]` means either match command `foo` or command `bar`\n directly followed by command `qux`, but backtrack on failure and ignore the\n group.\n* `(foo | bar qux)...` means either match command `foo` or command `bar`\n directly followed by command `qux`, repeatedly. During repetition another\n branch can be matched, so this is valid: `foo bar qux bar qux foo`. The output\n is: `{ \"foo\": 2, \"bar\": 2, \"qux\": 2 }`.\n\nThe following is true for all groups:\n\n* Groups can be repeated: `...`\n* Groups can be optional using brackets: `[ foo ]`\n* Groups can be required using parenthesis: `( foo )`\n* Groups must not be empty\n* Groups must contain 1 or more branches\n* Groups succeed if at least one branch succeeds\n* Multiple successful branch matches are weighted and scored\n\n##### 1.6.1. Matching branches\n\n**Branches** describe multiple mutually exclusive ways to parse a valid program.\nBranches can appear at the top-level or in any group. Since branches are\nmutually exclusive, only one branch can ever succeed. If multiple branches\nsucceed, the highest scoring winner is elected. Generally, the depth of the\nparse within the branch (that is how deep into the branch the parse succeeded)\nas well as the weighting of the matched arguments matters. Arguments that were\nsubstituted by values in environment variables, or by their defaults or empty\nvalues, will have a lower ranking score than those that were read from argv.\n\n#### 1.7. References - [options]\n\nThis is not a real argument and not part of the canonical specification. It is\nused to indicate that the entire \"options\" section should be expanded in it's\nplace. Since this approach lacks information about the relation between options,\noptions are all expanded as optional and are exchangeable with adjacent options\n([#57][issue-57]). One exception to this rule is where an option that\nis defined in the option section also appears directly adjacent to the\n`[options]` reference tag.\n\nFor example:\n\n```\nusage: prog [options] (-f | -b)\noptions:\n -f foo\n -b bar\n```\n\nThis program won't accept the input `-f -b` as `-f` and `-b` are declared\nmutually exclusive from one another.\n\nLikewise:\n\n```\nusage: prog [options] --foo ARG\noptions:\n -f, --foo ARG\n```\n\nHere, `--foo` won't be expanded again and hence remain required.\n\n---\n\n## Deviations from the original ###\n\n> This implementation tries to be compatible where sensible, but does cut ties\n> when it comes down to it. The universal docopt test suite has been adjusted\n> accordingly.\n\n* **Better Error reporting.** Let the user of your utility know why input was\n rejected and how to fix it\n* **Optional arguments.** Neodoc understands `--foo[=BAR]` (or `-f[=]`) as\n an option that can be provided either with or without an argument.\n* **Alias matches.** If `--verbose` yields a value, so will `-v` (given\n that's the assigned alias).\n* **Flags are optional by default**. There's arguably no reason to force the\n user to explicitly pass an option that takes no argument as the absence of the\n flag speaks — the key will be omitted from the output. This is also the\n case for flags inside required groups. E.g.: The group `(-a -b)` will match\n inputs `-a -b`, `-ab`, `-ba`, `-b -a`, `-b`, `-a` and the empty input. To\n disable this behaviour, enable `options.requireFlags` (see `neodoc.run`).\\\n Please note that the default behaviour may change in a future version of\n neodoc — refer to #61.\n* **All arguments in a group are always required**. This is regardless of\n whether or not the group itself is required - once you start matching into the\n group, all elements that are indicated as required have to be matched, either\n by value or via fallbacks.\\\n For example:\n ```sh\n Usage: prog []\n ```\n will fail `prog foo`, but pass `prog foo bar`. The rationale being that this is\n more general, since if the opposite behaviour (any match) was desired, it\n could be expressed as such:\n ```sh\n Usage: prog [[] []]\n ```\n* **No abbreviations:**\n `--ver` does not match `--verbose`.\n [(mis-feature in the original implementation)](https://github.com/docopt/docopt/issues/104)\n* **There is no `null`** in the resulting value map. `null` simply means not\n matched - so the key is omitted from the resulting value map.\n* **Smart-options**. Options can be inferred from groups that \"look like\"\n options: `Usage: foo [-f FILE]` would then expand to `Usage: foo [-f=FILE]`\n* **Environment variables**. Options can fall back to environment variables,\n if they are not explicitly defined. The order of evaluation is:\n 1. User input (per `process.argv`)\n 1. Environment variables (per `[env: ...]` tag)\n 1. Option defaults (per `[default: ...]` tag)\n* **Stricter document layout**. Neodoc imposes more restrictions on the format\n of the help text in order to achieve certain goals, such as:\n * Neodoc allows associating option aliases over newlines:\n\n ```\n options:\n -f,\n --foo this is foo\n ```\n\n * Neodoc does **not** require 2 spaces between option and argument. Instead,\n only those arguments that visually \"look like\" arguments are considered for\n binding (i.e. all-caps: `ARG` and in-angles: ``):\n\n ```\n options:\n -f,\n --foo ARG\n ```\n\n Should there be any ambiguity, the option can also be explicitly bound:\n\n ```\n options:\n -f,\n --foo=ARG\n ```\n\n The same is true for optional arguments:\n\n ```\n options:\n -f,\n --foo [ARG]\n -b,\n --bar[=ARG]\n ```\n\n * Neodoc is more conservative on learning about options in order to prevent\n subtly introducing options:\n\n ```\n usage: prog [options]\n\n options:\n\n --foo this is foo, and it is similar to some-command's\n --bar in that it does qux.\n ```\n\n Here, the author is talking about `--bar` in another context, so it should\n not be considered an option to the program. Neodoc figures this out based on\n indentation of the previous description start.\n * Neodoc allows interspersing spaces in between usage layouts:\n\n ```\n usage:\n prog foo bar\n\n prog qux woo\n ```\n\n it is important to not that in this format (above), identation of the layout\n **is required**.\n or:\n\n ```\n usage: prog foo bar\n\n or: prog qux woo\n ```\n\n * Neodoc requires an `Options:` section title in order to parse any options\n (see [#76][issue-76] for discussion). **note: I am interested in a proposal\n on how to lift this requirement**.\n\n## License ##\n\n<neodoc> is released under the **MIT LICENSE**.\nSee file `LICENSE` for a more detailed description of its terms.\n\n\n[docopt-orig]: http://docopt.org\n[POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html\n[issue-tracker]: https://github.com/felixSchl/neodoc/issues\n[playground]: https://felixschl.github.com/neodoc\n[issue-55]: https://github.com/felixSchl/neodoc/issues/55\n[issue-24]: https://github.com/felixSchl/neodoc/issues/24\n[issue-57]: https://github.com/felixSchl/neodoc/issues/57\n[issue-76]: https://github.com/felixSchl/neodoc/issues/76\n","maintainers":[{"name":"felixschl","email":"felixschlitter@gmail.com"}],"time":{"modified":"2022-06-21T00:12:50.317Z","created":"2016-04-02T02:27:58.920Z","0.0.1":"2016-04-02T02:27:58.920Z","0.0.2":"2016-04-02T02:39:54.877Z","0.0.3":"2016-04-02T22:46:21.361Z","0.0.4":"2016-04-04T16:39:28.022Z","0.0.5":"2016-04-07T17:42:49.615Z","0.0.6":"2016-04-10T16:45:16.768Z","0.0.7":"2016-04-12T16:48:34.913Z","0.0.8":"2016-04-17T23:52:28.633Z","0.0.9":"2016-04-20T19:38:34.961Z","0.0.10":"2016-04-24T21:20:05.851Z","0.0.11":"2016-04-25T19:53:55.512Z","0.0.12":"2016-04-27T07:58:47.360Z","0.0.13":"2016-04-30T17:48:58.227Z","0.0.14":"2016-05-02T02:13:00.161Z","0.0.15":"2016-05-03T09:16:40.673Z","0.1.0":"2016-05-05T01:18:49.731Z","0.2.0":"2016-05-10T00:34:30.257Z","0.2.1":"2016-05-10T20:13:13.013Z","0.3.0":"2016-05-24T17:44:38.013Z","0.4.0":"2016-06-06T17:26:43.964Z","0.5.0":"2016-06-16T17:16:10.488Z","0.6.0":"2016-06-22T16:37:24.209Z","0.6.1":"2016-06-24T00:30:46.900Z","0.7.0":"2016-07-02T19:27:50.806Z","0.0.0-required-flags":"2016-07-09T06:18:32.872Z","0.8.0":"2016-07-16T15:46:47.712Z","0.9.0":"2016-07-22T23:05:58.922Z","0.9.1":"2016-07-25T18:04:32.521Z","0.9.2":"2016-07-25T21:06:18.760Z","0.10.0":"2016-08-12T08:37:56.288Z","0.10.1":"2016-08-18T03:38:33.331Z","1.0.0-rc.0":"2016-10-08T16:03:09.114Z","1.0.0-rc.1":"2016-10-08T20:13:51.378Z","1.0.0":"2016-10-18T17:45:04.175Z","1.0.1":"2016-10-19T18:01:03.952Z","1.0.2":"2016-10-22T01:14:01.780Z","1.1.0":"2016-10-22T09:43:46.536Z","1.1.1":"2016-10-23T08:02:19.207Z","1.1.2":"2016-10-23T08:16:48.051Z","1.2.0":"2016-11-01T08:19:49.600Z","1.3.0":"2016-11-01T17:03:39.032Z","1.3.1":"2016-11-03T17:08:05.427Z","1.4.0":"2017-02-16T17:56:15.617Z","2.0.0-next":"2017-02-19T21:44:04.128Z","2.0.0-fix-94":"2018-02-19T15:27:16.552Z","2.0.0":"2018-02-19T16:27:13.759Z","2.0.1":"2018-07-03T23:03:29.656Z","2.0.2":"2018-07-03T23:15:59.742Z"},"homepage":"https://github.com/felixschl/neodoc#readme","keywords":["docopt","neodoc","cli","parser","parsing","argument","args","option","command"],"repository":{"type":"git","url":"git+https://github.com/felixschl/neodoc.git"},"author":{"name":"Felix Schlitter","email":"felixschlitter@gmail.com"},"bugs":{"url":"https://github.com/felixschl/neodoc/issues"},"license":"LicenseRef-LICENSE","readmeFilename":"README.md","users":{"rubiadias":true,"icodeforcookies":true}}
![\"NPM](\"https://badge.fury.io/js/neodoc.svg\"\n){kind=icon}
\n \n \n ![\"Build](\"https://travis-ci.org/felixSchl/neodoc.svg?branch=development\"\n)
\n \n \n ![\"Join](\"https://badges.gitter.im/felixSchl/neodoc.svg\"\n)
\n \n![\"preview\"](\"https://raw.githubusercontent.com/felixSchl/felixSchl.github.io/master/neodoc/neodoc.png\"\n)
\n