eslint/eslint — pull request #770 by btmills (2014-04-07 20:14:15+00:00)
Title: Replace optionator with nopt (fixes #769)

I'd like to submit [nopt](https://https://github.com/npm/nopt) as my preferred option for CLI parsing, based on some of the issues with [Optionator](https://github.com/gkz/optionator) outlined in #769. I believe this implementation meets the current requirements:

- [x] **Explicit type checks**

`lib/options.js` includes type information, verified by nopt.

- [x] **Automatic help text generation**

While this is not included in core nopt, [nopt-usage](https://github.com/zaach/nopt-usage) adds it.

- [x] **Suggestions for misspelled options**

Rather than suggesting a correct spelling, nopt matches a partially-spelled flag. For example, just by defining a single `--globals` flag, `--globals window`, `--global window`, and `-g window` all work. There are still explicitly-defined short flags for help, config, format, and version, maintaining parity with the current version. Personally I like the flexibility this gives, but I see how it could be a potential hangup.

- [ ] **Parses objects and strings, not just `process.argv`**

This is not supported in nopt; it only accepts an array, defaulted to `process.argv`. The only change required is to the tests, passing in arrays instead of strings, which is how the tests worked before the switch to Optionator. Though this is missing, I don't see it as terribly important. It might in fact be an advantage because it doesn't get tripped up by `exports:true`.

- [x] **Repeated flags**

From my perspective, this is the single biggest issue solved by using nopt. It came up when adding `--env` and `--globals`, and it will be a problem again when adding a flag to configure rules. See L29 in `lib/options.js` below - `options.env` will now be an array containing an element for each occurrence of `--env`, so the [originally-preferred](https://github.com/eslint/eslint/issues/692#issuecomment-38208490) syntax of `--env browser --env node` now works. I should note, however, that the comma syntax introduced in #745 is removed. Since that hasn't been shipped in a new version yet, it's not a breaking change, but I could add it back easily if desired.

If there's consensus on this and it gets merged, the `--globals` flag (#751) will only require a slight change, and I anticipate adding rules configuration via the CLI to finish #692 will be much simpler. Thoughts?