To invert the boolean value (or any unary operator, such as ~ or - for numbers) returned from promise with await, we should put the operator before the await keyword rather than after. But this is counterintuitive and error-prone.

e.g.

function returnFalse() {
  return Promise.resolve(false);
}

async function test() {
  if(await !returnFalse()) {
    console.log('ok');
  }  
}

test();

We might expect ok to be displayed, but it never does. Since we apply ! on the promise return by async function, which is meaningless in most cases. So it would be nice if any code that apply ! after await rather than before.

Here is the correct test():

async function test() {
  if(! await returnFalse()) {
    console.log('ok');
  }  
}

I think it will be a general issue when writing code with async/await. And I think linter should check fo r this case.

(async function () {

}());

Gratuitous parentheses around expression no-extra-parens

Ref babel/babel-eslint#186

Originally reported by @tikotzky.

See: eslint/eslint#5701

class {
    toggleLocationActiveState = () => {
        this.props.onActivateLocation(this.props.id);
    }
}

curiosity:foo gajus$ eslint -v
v1.2.1

/foo/index.js
  13:9   error  Unexpected `this`                       no-invalid-this
  13:39  error  Unexpected `this`                       no-invalid-this

Ref babel/babel-eslint#173 @gajus

What's the purpose of this rule? Isn't the ability to pause a function anywhere you want (even mid loop) the whole point of async functions? I don't get why someone would want to guard against this, I do it all the time. Is there an issue I'm not aware of?

Results in #63

I have a following code with default rule setting ("before").

async lockCallback(normalizedProfile, token) {
}

Fails with Unexpected space after * babel/generator-star-spacing

Using "after" fixes first issue, but causes another two for the following code

export function *iterateChildren() {
}

warning  Unexpected space before *  babel/generator-star-spacing
warning  Missing space after *      babel/generator-star-spacing

Using "both" or "neither" is unwanted, but essentially fixes the first issue.

"eslint": "~1.9.0",
"eslint-plugin-babel": "^3.1.0",
"eslint-plugin-react": "^3.16.1",
"babel": "~5.8.23",
"babel-core": "~5.8.34",
"babel-eslint": "~4.1.4",

In my team we like to align variable declarations, so we use no-multi-spaces to enforce that.
But we recently started working with babel-eslint to use ES7 features and our lint fails when we try to align class properties.

Code:

export class Login extends React.Component {
  canSubmit   = false;
  serverError = null;
}

.eslintrc:

{
  "plugins": [
    "react",
    "babel"
  ],

  "extends": ["eslint:recommended", "plugin:react/recommended"],

  "env": {
    "es6": true,
    "browser": true
  },

  "parser": "babel-eslint",
  "parserOptions": {
    "ecmaVersion": 6,
    "ecmaFeatures": {
      "jsx": true
    },
    "sourceType": "module"
  },

  "rules": {
    "no-multi-spaces": [1, {
      "exceptions": {
        "VariableDeclarator": true,
        "ImportDeclaration": true,
        "ImportSpecifier": true,
        "AssignmentExpression": true
      }
    }]
  }
}

Warning:

warning  Multiple spaces found before '='        no-multi-spaces

The configuration below raises "Configuration invalid" errors.

    'babel/object-shorthand': [2, 'always', {
      ignoreConstructors: false,
      avoidQuotes: true,
    }],

ESLint's space-infix-ops will catch:

/*eslint space-infix-ops: "error"*/

var a =2;

But, it won't catch a static property assignment:

/*eslint space-infix-ops: "error"*/

export class foo {
    static a =2;
}

I'd like to propose an extension to the space-infix-ops rule which would enforce spacing around assignment operators of static class properties.

code:

let x = [3, 2, 1, 0]
for (let [value, ] of x.entries()) {
  console.log(value)
}

error:

2:10  error  Expected consistent spacing  standard/array-bracket-even-spacing
2:16  error  Unexpected trailing comma    comma-dangle

Static class properties require a semicolon, as pointed out in https://phabricator.babeljs.io/T6873. Babel is now bombing with a compilation error if it doesn't find a semicolon. It would be super beneficial to have a linting rule to catch this.

Ref eslint/eslint#3658

Could you release a version using the babel-eslint 5.0.0-beta? It is needed when using babel 6.

Support for the comma-dangle ESLint rule for Flow type definitions.

The following is a nice idiom using decorators:

var Person = Model.extend({
  @attr firstName,
  @attr lastName
});

But eslint will then warn: error: "firstName" is not defined. (no-undef).

So it might be a good case to add a rule that allows this.

The following rules have had their effects added upstream:

• babel/generator-star-spacing: ESLint now supports async/await, and the upstream rule works fine
• babel/object-shorthand: This works upstream now
• babel/arrow-parens: async support works upstream; the only difference now is this handles Flow annotations and doesn't tell me that I have unnecessary parens when using (foo: mixed) => foo, and as such should probably go in eslint-plugin-flowtype
• babel/func-params-comma-dangle: Supported in comma-dangle as of ESLint v3.8.0

It would be ideal if we could warn when these rules are enabled, and look to removing them in the future.

There's currently no fully built-in way to warn on deprecated rules (see eslint/eslint#7443), but the pattern in eslint-plugin-react looks pretty good: https://github.com/yannickcr/eslint-plugin-react/blob/e1697996ff494bf584057418e2974ece7f3d99d8/lib/rules/wrap-multilines.js#L45-L53.

Modifier introduced in ESLint v3.3.0.

(eslint/eslint#6558)

I'd be happy to migrate it to https://github.com/gajus/eslint-plugin-flowtype.

const a = 1;
const b = do {
  a; // lint error here
}

Ref babel/babel-eslint#158 @jacobp100

babel-eslint to 6.x, eslint to 2.x (for testing), use phantomjs pre-built

Will probably have to copy the eslint tests from before because of the config changes.. (:cry:)

type Data = {
  type: string;
  payload: Object
};

export function test({type, payload}: Data) {
  console.log(type, payload);
}

There should be no space before 'Data'

Ref babel/babel-eslint#185

Like mentioned in the title, I can't get it to work in VS Code. More exactly, it fails when trying to parse ES7 syntax such as

async function a () {
   ...
}

or that also:

async () => {
   ...
}

I have used the same configuration like defined in the README https://github.com/babel/eslint-plugin-babel with the plugins babel and the list of rules.

In Atom, this works well though.

Is it related to the plugin, or related to VS Code?

This two lines of code break eslint:

const { ...something } = test;
const test = { ...something };

with this error (same for both of them):

error  There should be no space before '}'  computed-property-spacing

It won't break in this situation:

const test = {
    ...something
};

My .eslintrc file: http://pastebin.com/dBm79tb8

I think there should be an override for this.

Do I need this plugin to use async await with eslint? I can't seem to get it to work.

Ref eslint/eslint#3857

I am relatively still learning linting with eslint.

Can you please differentiate purpose of eslint-plugin-babel in comparison to babel-eslint vs eslint-plugin-babel ?

It seem's that the built-in rule for mandatory JSDocs (require-jsdoc) in classes is not accepting this:

/**
 * Class description
 */
@Bar
class Foo {

}

Only the following pass the validation:

@Bar
/**
 * Class description
 */
class Foo {

}

It would be nice if there was an override for require-jsdoc on this plugin to handle both situations :)

This is almost certainly my error, but after fiddling around for an hour I have not been able to figure out a solution. I'm trying to get object spread linting working with the following line of code:

const modelState = { ...defaultState, ...opts };

But I keep getting the error "Expected '}' to match '{' and instead saw '...'". My .eslintrc is at https://gist.github.com/edspencer/1ef8d41a040548d8af85 (I essentially copy/pasted that from the one referenced in #14).

I believe I have the correct options set in .eslintrc (spread is set true everywhere), but the syntax continues to be flagged as an error. My npm package versions of the pertinent plugins are as follows:

"babel": "^6.3.26",
"babel-core": "^6.4.5",
"babel-eslint": "^5.0.0",
"babel-loader": "^6.2.1",
"babel-plugin-external-helpers-2": "^6.3.13",
"babel-plugin-syntax-export-extensions": "^6.3.13",
"babel-plugin-syntax-flow": "^6.3.13",
"babel-plugin-syntax-jsx": "^6.3.13",
"babel-plugin-transform-es2015-arrow-functions": "^6.4.0",
"babel-plugin-transform-es2015-block-scoping": "^6.4.0",
"babel-plugin-transform-es2015-classes": "^6.4.5",
"babel-plugin-transform-es2015-computed-properties": "^6.4.0",
"babel-plugin-transform-es2015-constants": "^6.1.4",
"babel-plugin-transform-es2015-destructuring": "^6.4.0",
"babel-plugin-transform-es2015-for-of": "^6.3.13",
"babel-plugin-transform-es2015-modules-commonjs": "^6.4.5",
"babel-plugin-transform-es2015-object-super": "^6.4.0",
"babel-plugin-transform-es2015-parameters": "^6.4.5",
"babel-plugin-transform-es2015-shorthand-properties": "^6.3.13",
"babel-plugin-transform-es2015-spread": "^6.4.0",
"babel-plugin-transform-es2015-template-literals": "^6.3.13",
"babel-plugin-transform-flow-strip-types": "^6.4.0",
"babel-plugin-transform-object-assign": "^6.3.13",
"babel-plugin-transform-object-rest-spread": "^6.3.13",
"babel-plugin-transform-react-constant-elements": "^6.4.0",
"babel-plugin-transform-react-display-name": "^6.4.0",
"babel-plugin-transform-react-inline-elements": "^6.4.0",
"babel-plugin-transform-react-jsx": "^6.4.0",
"babel-plugin-transform-remove-react-styl": "^1.0.5"

Any ideas what I'm doing wrong? The spread operator inside of JSX is recognized just fine - it's just when I use it outside of the JSX context that I'm getting this error reported. Also, the code itself is transpiled just fine by webpack and the resulting code runs correctly in the browser. For completeness, here's a fuller snippet of my function (which github refuses to recognize as code for some reason):

`
export default function pagination(model, opts = {}) {
const defaultState = {
isLoading: false,
loadedAt: null,
items: [],
total: 0,
page: 1,
perPage: 50,
sortColumn: 'created_at',
sortDirection: 'desc'
};

const modelState = { ...defaultState, ...opts };

//more codes down here

}
`

From eslint/eslint#3354 (comment)

Async arrow functions always fail arrow-parens rule.

async () => {
}

Produces error:

error Expected parentheses around arrow function argument arrow-parens

@leebyron

Will probably have to be done here since async isn't standard yet

Tell us about your environment

• ESLint Version: 3.9.1
• Node Version: 6.8.0
• npm Version: 3.10.9

What parser (default, Babel-ESLint, etc.) are you using? [email protected]

Please show your full configuration:

{
	env: {
		'es6': true, // sets the "ecmaVersion" parser option to 6
	},
	parser: 'babel-eslint',
	plugins: [
		'babel'
	],
	rules: {
		'valid-jsdoc': 1
	}
}

What did you do? Please include the actual source code causing the issue.

/**
 * @class Whoops
 */
class Whoops {
	test = (wow) => {
		return wow;
	}
}

export default Whoops;

What did you expect to happen? No warning, test does not have a jsdoc tag

What actually happened? Please include the actual, raw output from ESLint.
1:1 warning Missing JSDoc for parameter 'wow' valid-jsdoc

If the method is changed to test(wow) { } then no warning is shown.

eslint reference: eslint/eslint#7555

There's a stage 1 proposal for callable class constructors that allows code like this:

import { initializeDate, ToDateString } from './date-implementation';

class Date {
  // `new Date()`
  constructor(...args) {
    initializeDate(super(), ...args);
  }

  // `Date()`
  call constructor() {
    return ToDateString(clockGetTime());
  }
}

And there's a babel transform for it.

But eslint doesn't seem to be able to handle it, even with this plugin. Am I configuring it wrong, or is this not supported?

I proposed this rule in an issue on eslint, but it was closed because they do not support experimental features.

This plugin says that it contains replacements to core ESLint rules. Would you relax that requirement and allow entirely new rules? If not, is there any place where a rule for ES7 would belong?

function fn() {
  return this.value;
}

const obj = {
  value: 42
};

obj::fn();

I can see why eslint proper doesn't support this usecase. Can eslint-plugin-babel provide a babel/no-invalid-this rule to support this usecase?

Not sure if this is the right repo for this issue, happy to go complain elsewhere :)

I'm running arrow-parens as-needed, but I'm also using flowtype. eslint complains that the parens are unnecessary on this type-annotated, single-parameter arrow function

const fn = (a: number) => {
  console.log(a);
};

I tried removing the parens, but that seems to be invalid syntax, as everything breaks at that point.

Parens around a single parameter are optional, however

 test() {
    [].filter(x => {
      console.log(x);
    });
  }

returns Expected parentheses around arrow function argument

Hi all!

I'm a maintainer of eslint-rule-documentation which is a tool that associates ESLint plugin rule names to the url of the rule's documentation page. This allows other tools (Atom's ESLint linter, Atom's XO linter, eslint-find-rules) to link to it easily, in linting errors for instance. This allows users to find the documentation page for a rule and read it to better understand why the error has been reported or learn how to configure it more to their needs.

In this example, import/no-extraneous-dependencies is a link that redirects to https://github.com/benmosher/eslint-plugin-import/blob/master/docs/rules/no-extraneous-dependencies.md.

To provide a better experience to the users, eslint-rule-documentation should in my opinion link to an individual documentation page, where the rule is described in a bit of detail (reasoning, how it works, valid and invalid examples, when not to use it...). That is the case for ESLint core rules, and for many ESLint plugins. It is unfortunately not the case of this plugin, and would therefore request that you consider making this change. The standard way of doing things (advocated by the ESLint team) is to have individual markdown files located at docs/rules/<rulename>.md.

In the case of the rules copying and improving the behavior of core ESLint rules, I would recommend a simple file that would link to the original rule and describe why it should be used instead of the core ESLint rule.
For custom rules, something that looks like this or that would be awesome.

We have to manually add support for each ESLint plugin in eslint-rule-documentation to create links correctly (see what it looks like), and would prefer waiting to add support for this plugin until you have either refused, or agreed and implemented the change. I could provide help for this, but I would only do the grunt work, as I'm not accustomed to the rules to be able to explain the rationale for each.

Thank you for considering this, and of course, thank you all for your hard work on Babel and the plugin, they're awesome!

I was just wondering when the latest release is coming out as the documentation in the README isn't what's available in the NPM module? This would be specifically around "array-bracket-spacing"

Installed as latest:

module.exports = {
  rules: {
    'generator-star-spacing': require('./rules/generator-star-spacing'),
    'new-cap': require('./rules/new-cap'),
    'object-curly-spacing': require('./rules/object-curly-spacing'),
    'object-shorthand': require('./rules/object-shorthand'),
    'arrow-parens': require('./rules/arrow-parens'),
    'no-await-in-loop': require('./rules/no-await-in-loop'),
  },
  rulesConfig: {
    'generator-star-spacing': 0,
    'new-cap': 0,
    'object-curly-spacing': 0,
    'object-shorthand': 0,
    'arrow-parens': 0,
    'no-await-in-loop': 0,
  }
};

Keep up the great work and thank you so much!

The object-curly-spacing rule doesn't seem to apply to objects that are in the second half of a hybrid import statement like:

import React, {Component, PropTypes} from 'react';

Is there any way to get the plugin to mark these kinds of objects? Or do I have to put the members object on its own line?

Would it be possible to update the "no-use-before-define" rule, so that the following code sample could pass: ?

type FooBar = Foo | Bar;
type Foo = { foo: string };
type Bar = { bar: number, baz: FooBar };

Since FooBar references Foo before it was declared, ESLint considers this an error. However type declarations are allowed to go in any order (for example so that recursive types can be supported), similar to functions.

packages:

npm ls --depth=0
...
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
...

code:

let a = function () {}

let b = function () {
  @a
  class X {
    constructor () {}
  }

  return new X()
}

b()

error:

3:21  error  Block must not be padded by blank lines  padded-blocks

eslint-plugin-babel version:

3.1.0

babel-eslint version:

5.0.0

eslint version:

2.1.0

I have following code.

class Foo {

    async print({a, b, c} = d) {

    }

    async spit() {
        await this.print({});
    }

    droll() {

    }
}

const foo = new Foo();

function zap() {

}

zap(foo);

Expected:

No errors

And got:

'd' is not defined.

What rules or ecmaFeatures should be enabled to get pass on this?

Right now the peerDependency for eslint is still in the 1.x.x version and npm complains:

npm ERR! peerinvalid The package [email protected] does not satisfy its siblings' peerDependencies requirements!
npm ERR! peerinvalid Peer [email protected] wants eslint@>=1.0.0

What needs to be done to support the latest eslint?

Thanks for all the great work!

eslint's no-duplicate-imports rule does not differentiate between import and import type statements, and babel-eslint alone cannot do anything about it: babel/babel-eslint#293

Perhaps we need a babel/no-duplicate-imports rule as part of this plugin which correctly handles the case when there's an import and import type statement for the same module?

With this code:

import {
  globalIdField,
  mutationWithClientMutationId,
} from 'graphql-relay';

🪲 I am told a space is required before , and after mutationWithClientMutationId.

I'm new to async await and find myself declaring functions as async but forgetting to await the promises inside of them (instead just calling let x = getData() or whatever. Would it make sense to have a rule that warned when you created an async function put didn't await inside that function?

I know you technically don't need await to use async, but might help some folks? Thoughts?

test.js

/*eslint array-bracket-spacing: [2, "never"] */
function fnArray([a, b]: Array<any >): void {
  // nothing important
}

What versions I'm using

[email protected]
[email protected]

What I did

$eslint --parser babel-eslint test.js

What I expected

No errors

What actually happened

/tmp/test.js
  2:36  error  There should be no space before '>'  array-bracket-spacing

✖ 1 problem (1 error, 0 warnings)

My Observations

The ArrayPattern node of the AST tree contains the type annotation.

function fnArray([a, b]: Array<any >): void {
//               ^-----------------^
//                ArrayPattern

The array-bracket-spacing rule checks the last and before last tokens of the AST node (ie. last is > an before last is any).

Since the between the before last token and last token their is a space and the expected is no space, an error is reported.

const fn = async (ctx, next) => {

}

Error:

error  Expected parentheses around arrow function argument  arrow-parens

is this an error on your side or is this invalid syntax? using [email protected] and [email protected]

This code breaks babel/arrow-parens rule:

const test = async (something) => {
    return something * 42;
};

test();

with this error

1:14  error  Expected parentheses around arrow function argument  babel/arrow-parens

My .eslintrc file: http://pastebin.com/zJW5KYTa

It should not throw this error.