vicompany / eslint-config-vi Goto Github PK

To discover missing rules.

https://www.npmjs.com/package/eslint-find-rules

We might want to allow native confirms?

• Update to ESLint 5.
• Add the new rules.
• Change/update current rules based on feedback.
• Update Changelog.
• Release v9.0.0.

const obj1 = {};
const obj2 = {};
const combinedObjects = { ...obj1 , ...obj2 };

Gives the following error: [eslint] Parsing error: Unexpected token ...

Instead of using the Airbnb/legacy config. CC @pimskie

Follow http://keepachangelog.com/

http://eslint.org/blog/2016/09/eslint-v3.6.0-released

{
    "parserOptions": {
        "ecmaVersion": 2016,
        "sourceType": "module"
    }
}

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

It generates too many errors in older projects because we did not enforce that before.

Make the files more generic.

We don't support IE8 anymore, you get cleaner diffs and you can type less. :)

https://medium.com/@nikgraf/why-you-should-enforce-dangling-commas-for-multiline-statements-d034c98e36f8#.5ppvkgve1

I agree with preventing console.log statements, but I do feel console.warn and console.error have there place and that the linter should not show warnings for these types of console messages.

• https://developer.mozilla.org/en-US/docs/Web/API/Console/warn
• https://developer.mozilla.org/en-US/docs/Web/API/Console/error

Enable the prefer-const rule.

First make it a warning and later (the next major) turn it into an error.

The config currently forces padding after consts, lets and vars.

Although I get the sentiment of separating assignments, it removes the freedom to decide what grouping is best per use-case. I often run into this when dealing with the DOM API.

Examples

This is a simple example that honours 8.0.0, but requires several context switches.

const canvas = document.createElement('canvas');
const container = document.createElement('div');

// Switch mental context to canvas
canvas.classList.add('my-canvas-class');

// Switch mental context to container
container.classList.append('my-container-class');
container.appendChild(canvas);

This is the same code but grouped by subject. It removes the need to switch context, but the whitespace feels excessive.

const canvas = document.createElement('canvas');

canvas.classList.add('my-canvas-class');

const container = document.createElement('div');

container.classList.append('my-container-class');

container.appendChild(canvas);

Solution

By either adding nuance or removing the variable declaration padding, developers get the freedom to choose how to group code.

const canvas = document.createElement('canvas');
canvas.classList.add('my-canvas-class');

const container = document.createElement('div');
container.classList.append('my-container-class');

container.appendChild(canvas);

80 characters is too little in many cases and forces us to write code in a different way solely for a linter.

There also seems to be buggy behaviour where some short lines are marked as too long, while lines that are too long pass the validation.

Should be turned off.
I agree with the comments in this thread: eslint/eslint#6820 (comment)

See https://eslint.org/blog/2020/02/whats-coming-in-eslint-7.0.0

Some nodejs/commonjs rules will be deprecated (in the near future) and put into a separate config, so we have to decide what to do with our node.js config.

In some cases array destructuring leads to verbose code. There is currently no way to circumvent using destructuring, except manually disabling it through the use of a comment.

Changing this rule from an error to a warning would give us more flexibility in this matter.

Enable padded-blocks for at least Classes.

We really would like to have something like: ['error', 'always' { blocks: 'never', switches: 'never'}] which implicitly means: classes: 'always' if I stand correctly?

Why are we not allowed to use continue in for loops?

For use in String.prototype.replace and (Webpack) configs.

As replacement for greenkeeper which doesn't seem to work anymore. It also checks node versions and has some other nice features.

https://renovateapp.com

http://eslint.org/docs/rules/line-comment-position

• Publish the last version with a special npm tag.
• Also drop support for Node.js 6: https://nodejs.org/en/about/releases/
• Update readme.

Switch to 'always' (default) for: http://eslint.org/docs/rules/arrow-parens

And 'as-needed' (default) for: http://eslint.org/docs/rules/arrow-body-style