manovotny / eslint-config-get-off-my-lawn Goto Github PK

View Code? Open in Web Editor NEW

55.0 4.0 8.0 1.31 MB

A highly opinionated, sharable config of ESLint rules to produce beautiful, readable JavaScript.

License: MIT License

JavaScript 100.00%

eslint eslint-config eslint-rules eslint-plugin

eslint-config-get-off-my-lawn's Introduction

eslint-config-get-off-my-lawn

A highly opinionated, sharable config of ESLint rules to produce beautiful, readable JavaScript.

As developers, we spend more time reading code than writing it. These rules aim to make reading JavaScript a priority.

That means some rules will feel oppressive or "over the top" for many developers, which is fine. If you don't like it, you can get off my lawn! ... Or extend the rules and override them with the ones that bother you. Either way. 😊

This config also comes with the following plugins, and corresponding rules, baked in.

Each and every single rule has been meticulously poured over and purposefully hand picked or excluded.

eslint-config-get-off-my-lawn will automatically enable and disable plugins (and thus rules) based on your package.json dependencies. Not using React? Cool. eslint-plugin-jsx-a11y, eslint-plugin-react, eslint-plugin-react-hooks, and eslint-plugin-react-native won't be included. Not using a React version that supports hooks? eslint-plugin-react-hooks will be disabled. Not a React Native project? No problem. Those rules won't be included. I think you get the idea... 😉

Install

NPM

$ npm i eslint eslint-config-get-off-my-lawn --save-dev

Yarn

$ yarn add eslint eslint-config-get-off-my-lawn --dev

Usage

Create an ESLint config in your package.json or .eslintrc.js file.

package.json

{
    "name": "my-awesome-project",
    "eslintConfig": {
        "extends": "get-off-my-lawn",
        "rules": {
            // enable additional rules, override rule options, or disable rules
        }
    }
}

.eslintrc.js

module.exports = {
    extends: 'get-off-my-lawn',
    rules: {
        // enable additional rules, override rule options, or disable rules
    },
};

Once your rules are configured, we recommend running the following command in your package.json as an npm script.

eslint . --ext .js,.json

Supported extensions:

.js
.jsx
.json
.json5
.jsonc
.ts
.tsx

Usage With Prettier

Love eslint-config-get-off-my-lawn? Love prettier? Well you're in luck!

eslint-config-get-off-my-lawn will automatically detect if your project is using prettier and it will apply eslint-config-prettier to turn off all rules that are unnecessary or might conflict with prettier.

Usage With TypeScript

But what about TypeScript? Don't worry, we got you!

eslint-config-get-off-my-lawn will automatically detect if your project is using TypeScript and it will configure and enable @typescript-eslint/eslint-plugin for you. How's that for handy?

prettier-config-get-off-my-lawn - A highly opinionated, sharable config of Prettier rules to produce beautiful, readable code.
stylelint-config-get-off-my-lawn - A highly opinionated, sharable config of stylelint rules to produce beautiful, readable CSS and Sass.

License

MIT © Michael Novotny

eslint-config-get-off-my-lawn's People

Contributors

Stargazers

Watchers

Forkers

jbrad tricomsol praneybehl don-smith benkiefer jjroush scottagirs lukeshay

eslint-config-get-off-my-lawn's Issues

Consider adding `eslint-plugin-prefer-object-spread`

https://www.npmjs.com/package/eslint-plugin-prefer-object-spread

Consider adding `eslint-plugin-xss`

https://www.npmjs.com/package/eslint-plugin-xss

Consider adding `node/prefer-promises/dns`

Once higher versions of node become more prevalent.

https://github.com/mysticatea/eslint-plugin-node/blob/master/docs/rules/prefer-promises/dns.md

Relax `react/display-name` rule

React display names are not necessary for code to React, but they do aid in debugging issues.

In most cases, React can intuitively and automatically determine what the display name should be. But in other cases, namely in anonymous usages, it is not able to determine a display name, which makes debugging some React errors / warnings very, very difficult.

Warning: Each child in an array or iterator should have a unique "key" prop. Check the top-level render call using <div>.

The proposition is to relax the react/display-name rule so it will only error on instances where a display name cannot be intuitively and automatically determined.

Recommendation is to change react/display-name's ignoreTranspilerName from true to false.

'react/display-name': [
    'error',
    {
        ignoreTranspilerName: false
    }
]

Add objects plugin

https://github.com/davidwaterston/eslint-plugin-objects

Add functional programming plugin

https://github.com/jfmengels/eslint-plugin-fp

Update eslint rules

We needed to upgrade eslint in order to fix #19, but I didn't want to add any new rules at this point in time.

At some point, we'll need to investigate what rules were added / deprecated between eslint 3.7.0 and 3.15.0 and do a breaking change.

Add json plugin

https://github.com/azeemba/eslint-plugin-json

Remove `prefer-reflect` rule.

It's going to be deprecated, so let's remove it.

http://eslint.org/docs/rules/prefer-reflect

Add mocha plugin

https://github.com/lo1tuma/eslint-plugin-mocha

Remove `div` from `react/forbid-elements`

While I have a strong disdane for divs they are still technically ok to use unlike the other deprecated elements in the list.

Relax `react/jsx-handler-names` rule

I don't understand the benefit of this rule to be honest. My biggest issue is the eventHandlerPropPrefix option. You might not have control over the naming of the functions that you are passed like router.goBack when using React Router.

Investigate rule duplication between `no-process-exit` and `unicorn/no-process-exit`

Remove duplicate rule for unlimited / abusive eslint disable

  0:1  error  Specify the rules you want to disable at line 1:0                                  unicorn/no-abusive-eslint-disable
  1:0  error  Unexpected unlimited 'eslint-disable' comment. Specify some rule names to disable  eslint-comments/no-unlimited-disable

Investigate rule conflict between `no-extra-parens` and `react/jsx-wrap-multilines`

Consider adding `require-atomic-updates` when it becomes more stable

As much as we want to include it, it's just too unstable right now and causes too many false positives right now.

Consider adding `require-optimization` from eslint-plugin-react

Essentially requires that shouldComponentUpdate be implemented for React classes.

I can see definite benefit, but does it force premature optimization?

https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/require-optimization.md

Consider removing `import/no-dynamic-require` rule.

import/no-dynamic-require seems to be too defensive. It's not common to dynamically require. It's rarely done maliciously, and more often than not, done intentionally. Seems silly to enforce something when it's purposefully ignored with a comment 99.5% of the time.

Add react plugin

https://github.com/yannickcr/eslint-plugin-react

Eslint is running super slow on larger projects using this config

Eslint run times seem to be taking > 1 minute when eslint should be running in < 10 seconds.

Consider changing how the config depends on eslint

Upon further research, it appears most configs have eslint listed in devDependencies and peerDependencies rather than in dependencies like get-off-my-lawn has.

Examples:

Consider adding `jsx-a11y/no-autofocus`

https://github.com/evcohen/eslint-plugin-jsx-a11y/blob/master/docs/rules/no-autofocus.md

Though in talking with UX peoples, they have mixed responses. The decision to use autofocus seems to be circumstantial.

This article probably describes how to best implement it.

http://www.brucelawson.co.uk/2009/the-accessibility-of-html-5-autofocus/

Consider removing or changing subjective rules

Let's take max-statements, for example... Say it's set to 10 lines. I then write this function that is 11 lines. Maybe it should be broken up into smaller, more easily consumable functions. Maybe the code makes more sense to stay together because it eloquently encapsulates a piece of functionality well. And that's the problem...

It depends.

Subjective rules like this are usually better left disabled and the kinds of things they try to prevent are better left to code reviews and conversations than hard and fast, black and white rules that arbitrarily force you to change the code or add a disable comment.

The following rules are in eslint-config-get-off-my-lawn and should be considered for removal, or at the very least, changed to a warning.

complexity
max-depth
max-nested-callbacks
max-params
react/no-set-state

'jsx-a11y/label-has-for': [
    'error',
    {
        required: {
            every: [
                'nesting'
            ]
        }
    }
]

Update to eslint 5

With the exception of the issue in #101, everything appears to work correctly.

Migration guide

I'd be happy to make an attempt at this if desired.

3:22  error  'assets-webpack-plugin' should be listed in the project's dependencies. Run 'npm i -S assets-webpack-plugin' to add it  import/no-extraneous-dependencies
3:30  error  "assets-webpack-plugin" is not found                                                                                    node/no-missing-require

Tip: Disallow known large imports from JavaScript projects with ESLint & the no-restricted-imports rule ~ great for helping teams avoid specific imports & recommending alternatives

🤔