Package Exports

@typedigital/eslint-config

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (@typedigital/eslint-config) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

@typedigital/eslint-config

npm

configurations

typedigital

Installation

npm i @typedigital/eslint-config --save-dev

Add an .eslintrc to the project's root directory with following content:

{
    "extends": [
        // base rule set
        "@typedigital/eslint-config"
    ],
    "env": {
        "node": true
    },
    // ignore configs in other directories
    "root": true
}

@typedigital/eslint-config/react

Additional rules for React development.

{
    "extends": [
        "@typedigital/eslint-config",
        "@typedigital/eslint-config/react"
    ],
    "root": true
}

@typedigital/eslint-config/react-native

Additional rules for React Native development. Should be used with typedigital/react rules.

{
    "extends": [
        "@typedigital/eslint-config",
        "@typedigital/eslint-config/react",
        "@typedigital/eslint-config/react-native"
    ],
    "root": true
}

Recommendations

disabling rules

Sometimes, there is a legitimate use-case to disable a specific rule. You can disable a rule for the current line like this

// eslint-disable-line rule-code

where rule-code is the code that is displayed along the error message.

In rare cases, it makes sense to disable a rule for the whole project. For instance, if you work with JSON data coming from a foregin API that uses underscore property names.

If you don't agree with a rule, please do not just disable the rule. It's better to create an issue here in order to discuss the pros and cons of a rule.

License

Unlicense