Is there a design decision on why the warnings feature of eslint is not used? One could consider marking only the real error-catching rules as errors, and the rest of styling distinctions as warnings.

This allows the users to prioritize efforts on fixing errors first, and the style second. More importantly, the currently proposed best practice of running standard as part of npm test results in quick test cycle (i.e. TDD) users being highly annoyed, as it is impossible to iterate quickly if every tiny styling issue breaks the tests. Warnings would not affect the return code, resulting in a better experience.

I just upgraded from 3.3.0 to 3.4.0 and now get this error:

TypeError: Error while loading rule 'spaced-comment': Cannot read property 'length' of undefined
at module.exports (C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\rules\spaced-comment.js:26:28)
at C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\eslint.js:629:32
at Array.forEach (native)
at EventEmitter.module.exports.api.verify (C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\eslint.js:620:16)
at processText (C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\cli-engine.js:200:27)
at processFile (C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\cli-engine.js:225:12)
at C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\cli-engine.js:317:26
at walk (C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\util\traverse.js:81:9)
at C:\r\larsthorup\amaze\node_modules\semistandard\node_modules\standard-engine\node_modules\eslint\lib\util\traverse.js:102:9
at Array.forEach (native)

This new rule syntax is not compatible with existing code and requires updates to other modules in order to work, namely the ones you bumped, eslint and eslint-plugin-promise. Packages that expect patches to be backwards compatible will fail if they list eslint and eslint-plugin-promise as dependencies and don't bump those as well. I'd recommend reverting this change in the 6.2.x branch and posting it in 6.3

standard:
    Configuration for rule "wrap-iife" is invalid:
    Value "any,[object Object]" has more items than allowed.

Installing this module on npm 3.5.4 gives:

$ npm install --save-dev eslint-config-standard
[email protected] /home/nfantone/dev/js/project
├── [email protected] 
└── UNMET PEER DEPENDENCY eslint-plugin-standard@^1.1.0

npm WARN [email protected] requires a peer of eslint-plugin-standard@^1.1.0 but none was installed.

Which forced me to manually install eslint-plugin-standard. Any chance this peerDependency could be moved to dependencies, instead?

I see that jsx-quotes is set to prefer-single (unlike the eslint default). While that would be seemingly consistent with the JS equivalent, the overwhelming majority of JSX out there uses double quotes because that is the preferred convention for XML and HTML (which JSX mimics).

Would you be inclined to change this rule?

Would it be possible to extract the JSX / React parts into a separate config (and remove them from this config)?

I have non-React JavaScript projects where it feels a bit weird having to install the ESLint React plugin just to be able to get a JavaScript Standard and Semi-Standard linting up and running.

This is such a useful shared config, I really appreciate the effort you've spent making it as comprehensive as it is. Great work!

I found it strange to have to install three different packages, instead of just one. Then I noticed they are specified as dependencies in package.json, albeit as peer dependencies.

Why can't they be just normal dependencies, and isn't peer dependencies deprecated?

So, we got #21 and that's great.

It got us instance–wide consistency.

Now, what about file–wide consistency, as was mentioned here?

And, now that I'm thinking about it, why not project–wide consistency?

And thinking further, why not choose a style as standard?

Either no spaces ({a, b}) or a single space ({ a, b }).

I recently discovered that eslint --init can automatically create a config extending this config if you choose Standard under Use a popular style guide. This also automatically installs peerDependencies, and I personally find it more convenient than the manual approach that's currently in the readme.

Would you be open to a PR adding an ESLint Markdown Plugin to apply Standard rules to fenced code in Markdown files?

I am the originator of the idea to split the react and jsx eslint rules into separate packages.

The jsx-quotes eslint rule should be entireley dropped.

The rule is bloat here. The suggested enforcement to use double quotes in the upcoming release #564 inevitably results in an infringement of the »single quotes for strings« rule.

Following #27 , some comments

(...) the overwhelming majority of JSX out there uses double quotes because that is the preferred convention for XML and HTML (which JSX mimics).

Excuse me, Sir. What majority are you talking about @pluma? Have you shown us some evidence or are you simply using your superior GitHub reputation as an argument? And no, you are wrong.

(...) because that is the preferred convention for XML and HTML (which JSX mimics).

Wew. Here we go again: JSX is intended to be used by various preprocessors (transpilers) to transform DOM tokens into standard ECMAScript and that's it. Nothing more. It's not a proposal to incorporate with the HTML spec itself.

Please change it back to prefer-double default value. That's the common convention in React community for JSX attributes (in opposition to JS strings).

I am sorry @dverbru. Is this some exclusive club you are talking about? Again: JSX is not restricted to only one framework.

(...) Also, to reiterate what the AirBnB style guide points out

You are making up a big story here @pluma. Who or what is AirBnB and why is it important here? This is not a beauty competition. This project is about coding-style. Some people prefer single quotes, others double quotes. Some prefer spicy meatballs over tendies.

But here's the good news: The original idea of standard was to define a common, simplified coding standard, based on a few simple rules. Very simple rules. @feross made it as simple as it gets.

And the rule states to use single quotes. Point. That's it. And if you have trouble to use double and single quotes in one string, you are always welcome to use template literals. And please don't worry. The preprocessor will take care of it.

Everyone is free to define his prefered configuration, I see no reason to include this rule by default.

{
  "rules": {
    "jsx-quotes": [2, "whatsoever"]
  }
}

I'd like to know if no-constant-condition has been considered to be added because it isn't a formatting rule and can help to detect buggy code.

http://eslint.org/docs/rules/no-constant-condition

I'm not trying to convince to add it, I'm just wondering if it has been missed than discarded.

Thanks

npm install eslint-config-standard causes UNMET PEER DEPENDENCY eslint@>=3.8.1

$ eslint -c .eslintrc.json ./
/Users/ian/git/redux-elm-skeleton/.eslintrc.json:
        Configuration for rule "wrap-iife" is invalid:
        Value "any,[object Object]" has more items than allowed.

Error: /Users/ian/git/redux-elm-skeleton/.eslintrc.json:
        Configuration for rule "wrap-iife" is invalid:
        Value "any,[object Object]" has more items than allowed.

[email protected] with .eslintrc.json

{
    "extends": "standard",
    "plugins": [
        "standard",
        "promise"
    ]
}

Getting the following error:

Error: standard: Configuration for rule "no-labels" is invalid: Value "2,[object Object]" has more items than allowed.

Using the following versions:

• "eslint": "^2.0.0-rc.1",
• "eslint-config-standard": "^5.1.0",
• "eslint-plugin-promise": "^1.0.8",
• "eslint-plugin-standard": "^1.3.2",

At the time of writing of this issue this package has version 10.2.1 but the official changelog (which is the one for standardjs) only goes up to 10.0.3 (2017-08-06). This incidentally brings quite a lot of errors on my existing codebase, most notably regarding indentation.

I feel there should be one of two things:

• a Changelog up to 10.2.1
• a beta or unstable tag on the published versions above 10.0.3

eslint version: 1.10.3
eslint-config-standard version: 5.0.0
eslint-plugin-promise version: 1.0.8
eslint-plugin-standard version: 1.3.1

Full error:

Error: standard:
    Configuration for rule "no-labels" is invalid:
    Value "2,[object Object]" has more items than allowed.

Referenced from: /private/tmp/immutable-redux/.eslintrc
    at validateRuleOptions (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:102:15)
    at /private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:148:13
    at Array.forEach (native)
    at Object.validate (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:147:35)
    at load (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:390:19)
    at /private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:326:36
    at Array.reduceRight (native)
    at applyExtends (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:309:28)
    at Object.load (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:395:22)
    at loadConfig (/private/tmp/immutable-redux/node_modules/eslint/lib/config.js:74:33)

Wasn't seeing this issue with eslint-config-standard 4.x.x...

I expected "bar" is defined but never used in this code, but got nothing.

function foo (bar) { 
  return true
}
foo()

I've found it's because of this setting. But I couldn't find the reason.

"no-unused-vars": [2, { "vars": "all", "args": "none" }],

https://github.com/feross/eslint-config-standard/blob/master/eslintrc.json#L104
http://eslint.org/docs/rules/no-unused-vars.html#args

I think it should be { "args": "all" } or { "args": "after-used" }.

It seems this change was made in this commit.
standard/standard@72765c2#diff-da50a6bc6687fde49b3a83e1f9ad2c4fR97

Is there still any reason that it doesn't check arguments?

I don't believe this rule should includeExports, because the following should not be considered an error:

import { foo } from 'bar'

export * from 'bar'

Turns out standard doesn't have this enabled for default.

Just a heads up that there are a lot of rules being deprecated in 2.0.0. Is an upgrade planned?

Running eslint with standard returns:

Error: standard:
Configuration for rule "spaced-comment" is invalid:
Value "data["1"].block.balanced" has additional properties.

"eslint": "^2.13.1",
"eslint-config-standard": "^6.0.0",
"eslint-plugin-promise": "^2.0.1",
"eslint-plugin-standard": "^2.0.0",
"standard": "^8.0.0"

I have created an ESLint utility module that I thought you might find useful.

The module is called eslint-index and you can read the full documentation on npm.

eslint-index provides a great deal of functionality including:

• List all available rules declared by ESLint and any plugins you have included
• Colour code rules depending on their status:
  • omitted (not declared anywhere in you ESLint config file)
  • 0|off (declared, but set to 0|off)
  • 1|warn
  • 2|error
• Display links to the rule documentation page next to each rule
• Filter/reject rules by their status and/or their group
  • status is as described above (omitted|off|warn|error)
  • group is eslint for the core ESLint rules or the name of any of your plugins like react|import|flowtype
• Format the output as a number or a table to get an overview of your rule settings
• Rules that have been marked as deprecated are removed from all outputs
• All of the above filters and formatting can be combined, for example:
  • filter omitted and off rules, output them as a list and display the rule doc links alongside
  • filter eslint rules and display the rule setting counters in a table

I wrote this plugin to aid the development of my own ESLint config settings and found it incredibly useful for keeping track of everything. I hope you find this module useful and please do let me know if you have any ideas on how to improve it.

Hello,

100% likely this is not your setup, but my feeble command line skills.

A project I've joined is set up to lint and warn via gulp, but not fix.

I've attempted to install everything and run, but I get the following on a small test project:

Dave $ eslint --fix ./code/* --debug
  eslint:cli Running on files +0ms
  eslint:glob-util Creating list of files to process. +37ms
  eslint:ignored-paths Looking for ignore file in /Users/Dave/test +5ms
  eslint:ignored-paths Could not find ignore file in cwd +0ms
  eslint:cli-engine Processing /Users/Dave/test/code/test.js +7ms
  eslint:cli-engine Linting /Users/Dave/test/code/test.js +1ms
  eslint:config Constructing config for /Users/Dave/test/code/test.js +1ms
  eslint:config Using .eslintrc and package.json files +0ms
  eslint:config Loading /Users/Dave/test/.eslintrc +1ms
  eslint:config-file Loading config file: /Users/Dave/test/.eslintrc +1ms
Cannot find module 'babel-eslint'
Error: Cannot find module 'babel-eslint'

I suspect it may be because of a mix of global and local install.

What's the recommended install, setup and commands to run a fix on files in projects?

Thanks

I see that the rules page shows:

var location = env.development
  ? 'localhost'
  : 'www.api.com'

But this will also pass:

var location = env.development
? 'localhost'
: 'www.api.com'

In fact, any indentation at all will pass, as long the line breaks appear where they should:

var location = env.development
   ? 'localhost'
       : 'www.api.com'

I suppose this is meant to allow the flexibility for:

var lovs8on = env.development
              ? 'localhost'
              : 'www.api.com'

Doesn't look like multiline-ternary and operator-linebreak can control indentation.

Getting a "Warning: Failed to load plugin promise: Cannot find module 'eslint-plugin-promise'" when referencing standard in my app. I can add it myself, but should it be added to dependencies instead of devDependencies?

I was wondering if you would be open to the idea of changing the value of the eqeqeq rule
from "always" to smart?

The reason I would like to see this change in Standard is I believe it makes more sense for the regular
equality operators == and != rather than their type-safe counterparts === and !== to be used
for typeof comparisons. This is because when you use the typeof operator you are guaranteed to
be working with strings so type checks seem a bit superfluous in this context (see documentation).

As far as performance is concerned, there's virtually no difference between the two flavours of the
equality operators so this should not be an issue. And as for backwards compatibility, the suggested
change is safe as we are relaxing the existing rule rather than making it stricter. In other words, people
will not need to change their code if we decide to go ahead with it.

Thanks for awesome project, it is my favorite ESLint config. What do you think about adding ChangeLog to it?

We with many other developers think that having ChangeLog is very important for every open source project: http://keepachangelog.com/en/0.3.0/

Of course, users can look into commits, but:

1. It requires more time, to open every commit.
2. Commits will be split to “breaking changes” or “add features”.

I know that maintaining big project need a lot of time (by my experience with PostCSS and Autoprefixer). And you always try to reduce maintaining time. But eslint-config-standard releases is rare. I keep ChangeLog in my every project :).

@feross What do you think?

I noticed that there are few ES2015 rules that you have not set: http://eslint.org/docs/rules/#ecmascript-6

I assume it's because these rules are not compatible with ES5 code, and this shared config straddles both ES5 and ES2015. Is there a way to split this shared config into separate ES5 and ES2015 projects, sort of like I have?

• https://github.com/jokeyrhyme/eslint-config-es5
• https://github.com/jokeyrhyme/eslint-config-es2015

Anyway, back on topic, if you knew your shared config was only going to be used on ES2015 projects, which of these addition ES2015 ESLint rules would to enable? What does JavaScript Standard Code Style look like in an ES2015 world?

should be updated to [2, "always", {"null": "ignore"}] according to the docs.

eslint-plugin-node@5 and a few subsequent versions are out now, this configuration should be updated to take advantage of it.

Can we make it work with babel-eslint so that experimental features like decorators can pass?

http://eslint.org/docs/4.0.0/user-guide/migrating-to-4.0.0

eslint v4 is in alpha right now

for the most part, seems that this package works fine with it, but there are probably some rule upgrades that are worth doing to take full advantage of it

I'm already using babel/eslint for a project and added eslint-config-standard with npm install --save--dev eslint-config-standard.

Adjusted my .eslintrc to extend standard and was hit by this

$ node_modules/.bin/eslint  src/
/vagrant/node-project/node_modules/eslint/lib/config.js:129
                    throw e;
                    ^

Error: eslint-config-standard:
        Configuration for rule "generator-star-spacing" is invalid:
        Value "[object Object]" must be an enum value.

Referenced from: /vagrant/node-project/.eslintrc
    at validateRuleOptions (/vagrant/node-project/node_modules/eslint/lib/config-validator.js:88:15)
    at /vagrant/node-project/node_modules/eslint/lib/config-validator.js:101:13
    at Array.forEach (native)
    at Object.validate (/vagrant/node-project/node_modules/eslint/lib/config-validator.js:100:35)
    at loadConfig (/vagrant/node-project/node_modules/eslint/lib/config.js:99:19)
    at /vagrant/node-project/node_modules/eslint/lib/config.js:123:46
    at Array.reduceRight (native)
    at loadConfig (/vagrant/node-project/node_modules/eslint/lib/config.js:111:36)
    at getLocalConfig (/vagrant/node-project/node_modules/eslint/lib/config.js:225:23)
    at Config.getConfig (/vagrant/node-project/node_modules/eslint/lib/config.js:363:22)

Tried to be clever and changed generator-star-spacing to simply 2 in node_modules/eslint-config-standard/eslintrc.json for testing, but then was hit by the next error:

Error: eslint-config-standard:
        Configuration for rule "indent" is invalid:
        Value "data["2"].SwitchCase" has additional properties.

Installing this package gave me 1.3.1; I'm using babel 5.8.29 and 3.1.30 -> is there any known incompatibility?

Having the following dependencies:

├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]

I get the following error:

» ./node_modules/.bin/eslint src/index.jsx
standard:
    Configuration for rule "no-constant-condition" is invalid:
    Value "[object Object]" has more items than allowed.

Referenced from: /Users/michael/Liip/liiptalk/react-redux-tutorial/.eslintrc
Error: standard:
    Configuration for rule "no-constant-condition" is invalid:
    Value "[object Object]" has more items than allowed.

downgrading to [email protected] works. However if you just run npm install --save-dev eslint-config-standard it will default to using the 6.0.0-beta.0

'standard' style is my favorite coding style. Now I want to add the rule 'strict'(http://eslint.org/docs/rules/strict) for my project, but I find this rule doesn't work when sourceType is module(http://eslint.org/docs/rules/strict#rule-details). Finally, I can solve this problem by set the parserOptions manually in the config file.

Out of curiosity, why set 'sourceType' to module?

I try to remove this option. It can pass tests of eslint-config-standard and standard(see https://travis-ci.org/flowmemo/standard/jobs/192968809, I remove the option from node_modules/eslint-config-standard/eslintrc.json).

Thanks.

[email protected] isn't tagged as "beta" on npm and is therefore automatically marked as "latest".
This causes automated checking of dependencies to give false positives.

Just tried to install eslint for the first time following the readme and I got the following errors with eslint --init choosing the standard config.

What version of ESLint are you using?
3.0.1

Please show your full configuration:

{
    "extends": "standard",
    "plugins": [
        "standard"
    ]
}

What did you expect to happen?
Successful --init

What actually happened? Please include the actual, raw output from ESLint.
eslint-config-standard doesn't claim to support the current version of eslint.

$ npm install --save-dev eslint
[email protected] node_modules/eslint
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] ([email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected])
├── [email protected]
├── [email protected] ([email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected])
└── [email protected]
$ eslint --init
? How would you like to configure ESLint? Use a popular style guide
? Which style guide do you want to follow? Standard
? What format do you want your config file to be in? JSON
Installing eslint-plugin-standard, eslint-config-standard
npm WARN peerDependencies The peer dependency eslint@^2.0.0-rc.0 included from eslint-config-standard will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency 
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.
npm WARN peerDependencies The peer dependency eslint-plugin-promise@^1.0.8 included from eslint-config-standard will no
npm WARN peerDependencies longer be automatically installed to fulfill the peerDependency 
npm WARN peerDependencies in npm 3+. Your application will need to depend on it explicitly.
npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "i" "--save-dev" "eslint-plugin-standard" "eslint-config-standard"
npm ERR! node v4.2.6
npm ERR! npm  v2.14.12
npm ERR! code EPEERINVALID

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants eslint@^2.0.0-rc.0

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/rgant/Programming/.../npm-debug.log
Successfully created .eslintrc.json file in /Users/rgant/Programming/...
$ npm --version
2.14.12

I originally raised this issue with eslint: eslint/eslint#6617

eslint -v

v4.2.0

eslint --init

? How would you like to configure ESLint?
  Answer questions about your style
❯ Use a popular style guide
  Inspect your JavaScript file(s)

? Which style guide do you want to follow?
  Google
  Airbnb
❯ Standard

? What format do you want your config file to be in? (Use arrow keys)
❯ JavaScript
  YAML
  JSON

.eslintrc

{
  "extends": "standard"
}

run eslint error

$ eslint app.js
Cannot find module 'eslint-config-standard'
Referenced from: /xxx/.eslintrc
Error: Cannot find module 'eslint-config-standard'

Hi,
I get an error with eslint 2.0

➜  test-standard node_modules/.bin/eslint index.js
standard:
    Configuration for rule "spaced-comment" is invalid:
    Value "data["1"].block.balanced" has additional properties.

Referenced from: /Users/liqingwei/Documents/projects/test/test-standard/.eslintrc.js

➜  test-standard npm list --depth=0
[email protected] /Users/liqingwei/Documents/projects/test/test-standard
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

my eslintrc

module.exports = {
  "extends": "standard",
  "plugins": [
      "standard",
      "promise"
  ]
};

I see peerDependencies, It is should support eslint 2.0, right?

I get an error running eslint . --ext .js with

"eslint": "^1.0.0",
"eslint-config-standard": "^4.0.0-5",

Error: eslint-config-standard:
Configuration for rule "indent" is invalid:
Value "data["2"].indentSwitchCase" has additional properties.

It appears that shortly before the 1.0.0 launch, eslint was changed to use the rule

"indent": [2, 2, { "SwitchCase": 1 }],

instead of:

"indent": [2, 2, { "indentSwitchCase": true }],

See:
eslint/eslint@333fb6c#diff-c391782b252c49c8bc25c8769afa7eb7

Please clarify how this package follows the versioning of 'standard'. After the major version upgrade from 6 to 7, the newly enforced no-unused-expressions rule affected me. At first I didn't understand why, as that rule was introduced in standard/v9, and it wasn't obvious to me that this package enforces standard/v7 until I looked at the actual commits.

So, please clarify this.

When I use destructuring in a function signature I got this error:

[eslint] Parsing error: Illegal 'use strict' directive in function with non-simple parameter list

Example:

getAvailabilitiesOneWay ({ origin, destination, departureDate, valueComposition }) { ... }

Is there a reason why the no-shadow isn't defined?

This is a pretty common source of errors in code.

I found that the eslint-plugin-standard version in the peerDependencies should be >=2.1.0 because standard v10 requires the non-callback-literal rule which was added after the version 2.0.1

npm install eslint-config-standard causes UNMET PEER DEPENDENCY eslint@>=3.8.1 however, the latest version of eslint is v3.19.0, https://github.com/eslint/eslint/releases

I have installed the config in my project without errors, but when I try to install globally, I get this:

STARYU:~ stevelombardi$ npm install -g eslint-config-standard
/Users/stevelombardi/.nvm/versions/node/v5.10.0/lib
├── UNMET PEER DEPENDENCY eslint@^2.0.0-rc.0
├── [email protected] 
├── UNMET PEER DEPENDENCY eslint-plugin-promise@^1.0.8
└── UNMET PEER DEPENDENCY eslint-plugin-standard@^1.3.1

npm WARN [email protected] requires a peer of eslint@^2.0.0-rc.0 but none was installed.
npm WARN [email protected] requires a peer of eslint-plugin-promise@^1.0.8 but none was installed.
npm WARN [email protected] requires a peer of eslint-plugin-standard@^1.3.1 but none was installed.

Yet I have those installed. In fact, it seems eslint-config-standard did actually install:

STARYU:~ stevelombardi$ npm -g ls --depth 0
/Users/stevelombardi/.nvm/versions/node/v5.10.0/lib
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

When running in latest ESLint, I get the following error:

Module build failed: Error: standard:
        Configuration for rule "comma-dangle" is invalid:
        Value "[object Object]" must be an enum value.