eslint-config-suiyobi

"Enterprise Grade Linting"

Philosophy

When coding at scale ensuring high quality code as a project ages can prove difficult. Linting can drastically improve code quality by front loading many of the issues that should be caught in code review to the point where a developer has the most context.

Eslint is a really powerful tool that can do a lot, but there are some things it is better at than others. These configurations aim to focus on what it is good at. Namely improving code quality by making patterns more consistent and encouraging the use of modern language features.

Special Cases

The goal isn't to prevent patterns from being used, but instead to encourage good patterns by default and documenting where patterns need to be broken via required descriptions on disable directives.

If for example I have a valid use case for a file to be longer than 1000 lines long then I can disable max-lines with the following directive.

/* eslint-disable max-lines -- This file needs to include all it's dependencies so that they remain private */
...
/* eslint-enable max-lines -- Close disabled rule */

Requiring descriptions like this not only encourages thought about why this pattern is being broken by the developer but by the entire team during code review and future developers coming back to add to and refactor this code.

Code Formatting

Code formatting is extremely useful when working on a team as it as it reduces the number of changes that aren't meaningful leaving only the important parts for code review. Additionally having consistent formatting makes code much easier to read and switch contexts in the code base.

But, linting works best when it is showing you meaningful warnings and potentially unexpected behavior. Code Formatting rules just increase the noise which which makes more important warnings seem less important.

As such these configurations do not include any code formatting (quote style, indenting, spacing, etc.) rules. There are much better tools out there (prettier) for code formatting so I would encourage you to use those and enable format on save before you consider overriding the eslint configurations with code formatting rules.

Usage

1. Install the configuration

   npm install -D eslint-config-suiyobi

2. Add a .eslintrc.js to the root of your project that looks something like this

   module.exports = {
     overrides: [
       {
         extends: [
           'suiyobi/typescript',
           'suiyobi/angular',
           'suiyobi/rxjs',
           'suiyobi/ngrx',
         ],
         files: '**/!(*.spec).ts',
         parserOptions: { project: './tsconfig.json' },
       },
       {
         extends: ['suiyobi/typescript', 'suiyobi/jest'],
         files: '**/*.spec.ts',
         parserOptions: { project: './tsconfig.json' },
         settings: { jest: { version: 26 } },
       },
       {
         extends: ['suiyobi/angular-template'],
         files: '**/*.html',
         parserOptions: { project: './tsconfig.json' },
       },
       {
         extends: ['suiyobi/javascript', 'suiyobi/node'],
         files: '**/*.js',
       },
       {
         extends: ['suiyobi/markdown'],
         files: ['*.md'],
       },
       {
         extends: [
           'suiyobi/javascript',
           'suiyobi/node',
           'suiyobi/markdown-snippet',
         ],
         files: '*.md.js',
       },
       {
         extends: [
           'suiyobi/typescript',
           'suiyobi/angular',
           'suiyobi/rxjs',
           'suiyobi/ngrx',
           'suiyobi/markdown-snippet',
         ],
         files: '*.md.ts',
         parserOptions: { project: './tsconfig.json' },
       },
     ],
     root: true,
   };

   You can adjust the configuration to the needs of your project. You may also consider making a configuration for each package if you are using a monorepo to apply the proper platform configurations where they are applicable.

Entry Points

Each of your extends should consist of either a platform, framework and one or more utils OR a other-parser.

['<platform>', '<framework>', ...utils];
// OR
['<other-parser>'];

The supported entry points are

Platforms

• suiyobi/javascript
• suiyobi/typescript

Frameworks

• suiyobi/angular
• suiyobi/cypress
• suiyobi/jest
• suiyobi/node
• suiyobi/react
• suiyobi/react-native

Utils

• suiyobi/lodash
• suiyobi/markdown-snippet
• suiyobi/ngneat
• suiyobi/ngrx
• suiyobi/ramda
• suiyobi/rxjs

Other Parsers

• suiyobi/angular-template
• suiyobi/markdown

Rules Overriding

Depending on your project, you may choose to override or add additional rules. To do this simply add a rules with any rules you wish to override under the specific overrides where the rule applies.

Mono repo import sorting

If you wish to sort your can add this rule to your configuration replacing <your-project> with the namespace of your packages.

module.exports = {
  // ...other settings
  rules: {
    'import/order': [
      'warn',
      {
        'alphabetize': {
          caseInsensitive: false,
          order: 'asc',
        },
        'groups': [['external', 'builtin'], 'internal', 'parent', 'sibling'],
        'newlines-between': 'always',
        'pathGroups': [
          {
            group: 'external',
            pattern:
              '{@angular/**,@nestjs/**,react,react-native,react-*,@vue/**,vue}',
            position: 'before',
          },
          {
            group: 'external',
            pattern: '@<your-project>/**',
            position: 'after',
          },
        ],
        'pathGroupsExcludedImportTypes': ['react'],
      },
    ],
  },
};

Credits

This project forks eslint-config-intense for a very strong base of linting and tooling. Huge thanks to @dimitropoulos and his great work in setting up strong rules. Additional thanks to my co-workers Samuel and Derek for introducing me to some linting concepts (todo-expiration) and libraries (ramda).