General design/implementation strategy?

[Kevin Partington]

How do we even want to implement this CLI tool?

There are a few potential patterns:

• Support local and global usage
  • Not much value-add over current ESLint executable unless the global eslint-cli can detect/find local ESLint
• Support global usage but always look for local ESLint ("the Grunt pattern")
• Others?

I feel that we should agree on a general direction/architecture/design before we do too much else with this repository, personally.

[Toru Nagashima]

Thank you for this issue.

My personal goal is that we can use the following "Getting Started":

npm install -g eslint-cli
eslint --init    # and answer...
eslint foo.js

So requirements are:

• it allows us to use the shorter command eslint rather than node_modules/.bin/eslint.
• it can execute the local installed ESLint to verify and fix.
• it can show an understandable message if the local installed ESLint was not found, rather than using the global installed one.
• it can execute --init without the local installed ESLint in order to install ESLint into the local.

That's all. I think that this is similar to the Grunt pattern.

#10 may be useful to play small code on the outside of project directories. But my goal doesn't include it.