Eslint config

[ThijsTyZ]

This adds an Eslint Configuration Extension. This configuration has all eslint settings for React, Vue and Muban projects.

When installing this as an NPM library the .eslintrc.js can just be:

module.exports = {
  extends: ['@mediamonks']
};

[pigeonfresh]

The comment was refering to adding .vscode to the gitignore. So it's out of context here.

[ThaNarie]

I won't go through all the individual settings, we just have to start using it in a project, and tweak this config when we get annoyed by some rules, or are missing other rules, and go from there.

It seems we're adding/changing quite a lot of rules. It might be very useful to have an explanation for each rule (in a separate readme) with an explanation of why we have configured it that way. Not everyone might agree with the reasoning, but at least people can understand why. Or counter specific arguments made there that were not previously considered.

Also, it would be good to set guidelines on how to propose/discuss changes. E.g. opening an issue with the subject [add/change/remove] rule-name, and a template with the current and proposed setting, and the reasoning why.

[psimk]

what about eslint-plugin-jsx-a11y ?
This would also work for using JSX within Vue. My thinking is that, instead of accessibility being an afterthought, this plugin could at least guide us into a somewhat correct right direction from the get go. This could save time for both us and QA.

[psimk]

Typescript from version 3.8 supports import type, @typescript-eslint/eslint-plugin has a rule @typescript-eslint/consistent-type-imports that prevents types from being imported without the type prefix. This can rule can be quite invaluable when trying to restrict importing TS modules.
Example being webpack dynamic bundle splitting.

[ThaNarie]

@psimk TS itself also has an option (importsNotUsedAsValues) that throws errors, do we want both TS and eslint to complain? (Also, see #12)

[psimk]

@ThaNarie importsNotUsedAsValues would throw an error, but would it be auto-fixed? With the eslint rule we can at least guarantee that the rule won't trip over the developer and be auto-fixed, while still doing work in the IDE.