thenativewebeslint-config-es
eslint-config-es contains a strict ESLint configuration for ES2015+ and TypeScript.
Status
| Category | Status |
|---|---|
| Version |  |
| Dependencies |  |
| Dev dependencies |  |
| Build |  |
| License |  |
Installation
$ npm install eslint-config-es \
eslint
The following additional ESLint plugins are included by default, so you don't have to install them:
| Plugin | Automatically enabled |
|---|---|
| eslint-plugin-eslint-comments | Yes |
| eslint-plugin-extended | Yes |
| eslint-plugin-mocha | Yes |
| eslint-plugin-react | No |
| eslint-plugin-unicorn | Yes |
| @typescript-eslint/eslint-plugin | No |
To enable support for React and JSX, all you need to do is to install the react module. The appropriate rules will become enabled automatically.
To enable support for TypeScript, all you need to do is to install the typescript module. The appropriate rules will become enabled automatically for .ts and .tsx files. The generated configuration expects a tsconfig.json at the project root.
Quick Start
This module contains a very strict ESLint configuration for ES2015 and above, both for Node.js and browser development. Its aims to eradicate any variation in code style. If you can not tell any more, based on little individual manners, who of your co-workers wrote a piece of code, this module succeeded. This helps you to narrow down your focus to pure functionality, as you do not have to think about code styling any more at all.
To use one of those configurations, create a .eslintrc.json file in your project and use the extends keyword.
{
"extends": "es/node"
}
Alternatively, you may also use es/browser.
If you want to override any rules, you can do so in your configuration file. For details on how to do this, e.g. to get an explanation on how to enable or disable specific rules, see the ESLint documentation on extending configuration files.
Running quality assurance
To run quality assurance for this module use roboter:
$ npm run roboter
Note: npx roboter will not work as our ESLint Rules are written in TypeScript, so they have to be compiled before usage. npm run roboter will do this.
Better ESLint Rules
This package has a built-in library that allows defining ESLint-Rules in a more strict but (what we think) better and intuitive format.
A basic example looks like this:
const betterRulesRecord: BetterRulesRecord = {
camelcase: false, // compiles to "camelcase: 'off'"
forDirection: [], // compiles to "for-direction: 'error'"
noParens: [ 'always', { otherConfig: 'value' } ], // compiles to "no-parens: [ 'error', 'always', {otherConfig: 'value' } ]"
}
To be able to use those rules with ESLint, they have to be compiled with the betterRules.compile method. The whole betterRules package is exported by this library and can be used like this:
import { betterRules } from 'eslint-config-es';
const compiledESLintRules = betterRules.compile(betterRulesRecord);
// Will produce:
{
camelcase: 'off',
'for-direction': [ 'error' ],
'no-parens': [ 'error', 'always', { otherConfig: 'value' } ],
}
Differences to normal ESLint Rules
- Only 2 allowed rule-configs exist:
falsefor turning it off.[](possible empty) to turn it on with severityerrorand provide additional configuration.
- Rules are now in camelCase.
- error is the default and only for all rules.
withPlugin-Hook
You can use the withPlugin hook to avoid having to put plugin-rules in quotes ('react/test-rule') like this:
import { betterRules } from 'eslint-config-es'
const reactRules: BetterRulesRecord = betterRules.withPlugin('react', {
booleanPropNaming: false
});
Plugin names do not get compiled
Thus, you can use this hook to avoid weird constructs and streamline your configs:
const weirdMix: BetterRulesRecord = {
'@typescript-eslint/arrayType': []
};
const betterDefiniton: BetterRulesRecord =
betterRules.withPlugin('@typescript-eslint', {
arrayType: []
};
But why?
- Turning Rules off with
falserather than with a string'off'is easier to distinguish from turned on rules and strictly avoids typos (falsewill yield a compiler error if mistyped). - We do not see a value in ESLint
warnings, as warnings tend to get ignored. - Because of 2., there is no need for additional abilities to turn on a rule (
true, or a string), thus only allowing arrays[]streamlines and simplifies the configuration a lot. - CamelCasing the rules avoids the need to sometimes type property-keys of rules with quotes
'(e.g.{ 'for-direction': 'off'}), thus again streamlining configuration.