make eslint a peerDependency

[nlf]

should probably also relax the version required.

as it is now, we have an interesting situation where we have our own eslint config module that requires eslint-plugin-hapi (which in turn requires this module, which requires eslint 0.x.x).

we also require lab for testing, which installs eslint 1.8.

that's all well and good, but npm is silly and puts the binary for eslint 0.x.x in node_modules/.bin/eslint rather than the one for 1.8.0. we have an npm tree that looks like this (filtered by npm ls eslint):

nsp@2.0.1 /Users/nathan/Projects/nodesecurity/nsp
├─┬ eslint-config-nodesecurity@1.1.0
│ └─┬ eslint-plugin-hapi@2.0.0
│   └─┬ no-shadow-relaxed@1.0.1
│     └── eslint@0.24.1
└─┬ lab@7.1.0
  └── eslint@1.8.0

if we make eslint a peerDep and relax the versioning, it should just use the version brought in by lab and be happy, which would also solve the weird mishap we have with the much older eslint being the version linked in node_modules/.bin

[pdehaan]

FWIW, npm@3 (currently shipping in Node 5, I believe -- see changelog), peerDependencies will no longer resolve or be installed. See https://github.com/npm/npm/blob/master/CHANGELOG.md#peerdependencies for more information. Notably:

peerDependencies no longer cause anything to be implicitly installed. Instead, npm will now warn if a packages peerDependencies are missing, but it's up to the consumer of the module (i.e. you) to ensure the peers get installed / are included in package.json as direct dependencies or devDependencies of your package.

[pdehaan]

I think the solution would be to not explicitly install eslint as a dependency, devDependency, or peerDependency at all and leave that up to the user to install it in their package.json. It would get weird if every ESLint custom config and plugin tried to install their own different version of ESLint and you ended up with 5 different versions in your node_modules directory.