werk85 / eslint-config-werk85 Goto Github PK

"import/first": "error",
"import/newline-after-import": "error",
"import/no-named-default": "error",
"import/no-relative-packages": "error",
"import/no-useless-path-segments": "error"

See Documentation here: https://github.com/import-js/eslint-plugin-import

Führt zu false positivies wenn andere map Funktionen wie z. B. O.map verwendet werden.

Wollen wir diese - z.B. in SBF-Fragen 2.0 verwendete - Regeln in unser großes Regelset übernehmen?

 "@typescript-eslint/naming-convention": [
      "error",
      {
        "selector": [
          "variable",
          "typeProperty",
          "parameter"
        ],
        "types": [
          "boolean"
        ],
        "format": [
          "PascalCase"
        ],
        "prefix": [
          "can",
          "did",
          "disable",
          "has",
          "is",
          "should",
          "show",
          "will",
          "with",
          "$can",
          "$did",
          "$disable",
          "$has",
          "$is",
          "$should",
          "$show",
          "$will",
          "$with"
        ]
      }
    ]
  

import … from '.' can be prevented by using no-restricted-imports with following rule configuration:

'no-restricted-imports': [
  'error',
  {
    paths: ['.']
  }
]

Result:

A new separate rule set should be created with the name werk85/jest that can be added on demand, this allows to use the modern rule in projects that do not use jest like the yacht-navigator-app.

https://eslint.org/docs/rules/quotes

Suggest rule setup

{
  "quotes": [
     "error",
     "single",
     {
       "allowTemplateLiterals": false,
       "avoidEscape": false
     }
  ]
}

In vielen Projekten haben wir folgend Regel um nicht aus lib/* Verzeichnissen zu importieren:

    "no-restricted-imports": [
      "error",
      {
        "patterns": [
          {
            "group": [
              "*/lib/*"
            ],
            "message": "Use the non lib import instead"
          }
        ]
      }
    ],

I found few interesting rules for react to ensure code style and eventual perfomance issues. I would like to add

'react/void-dom-elements-no-children': 'error',
'react/self-closing-comp': 'error',
'react/jsx-curly-brace-presence': ['error', 'never'],
'react/jsx-no-constructed-context-values': 'error'

Those are the most interesting I found from the list of rules of eslint-plugin-react apart from the recommended which are already added.

Another is

'react/jsx-no-useless-fragment': 'error'

though it is in conflict with our empty React component (i.e. <></>) which is then marked as useless.

Do we want to add the object-shorthand rule to be concise with the syntax. Especially for older projects this is of interest because it is automatically fixable.

The original plugin was updated to support eslint 8 and seems to be actively supported again. A change back from the currently used unofficial fork is now possible. See gund/eslint-plugin-deprecation#39

See: import-js/eslint-import-resolver-typescript#31

[email protected]: this package has been deprecated, please use v2.0.0

Verwendung:

This option has been deprecated in v2.4.0, use --bracket-same-line instead

Dos für bracketSameLine

There are some plugins that have still open issues before an upgrade is possible:

• eslint-plugin-deprecation
  • Replaced with @delagen/deprecation
• eslint-plugin-react
• eslint-plugin-react-hooks - available in next release.
• eslint-plugin-jest

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html#eslint

https://github.com/buildo/eslint-plugin-fp-ts

https://typescript-eslint.io/rules/strict-boolean-expressions

@ankrut can you test this on a bigger code base and give me feedback? Maybe you find some bugs like I did.

This will change how code is formatted in all depending projects.

I suggest to add the arrow-body-style rule, to ensure consistent styling of arrow bodies. I would take the default settings which seem most convenient.

The main motivation is to convert arrow functions with unnecessary block style to an expression style. An unnecessary block style would look like

const foo = () => {
  return 'bar'
}

// auto-fixable to
const foo = () => 'bar' 

The eslint rule is

'arrow-body-style': ['error', 'as-needed']