https://github.com/dhi/eslint-config-dhi

✔/ ⭕ DHI's eslint base config. Use it to keep code consistent and avoid common JS pitfalls.
https://github.com/dhi/eslint-config-dhi

eslint eslint-config javascript linter linter-config

Last synced: 3 months ago
JSON representation

✔/ ⭕ DHI's eslint base config. Use it to keep code consistent and avoid common JS pitfalls.

• Host: GitHub
• URL: https://github.com/dhi/eslint-config-dhi
• Owner: DHI
• License: mit
• Created: 2018-02-13T14:07:12.000Z (over 7 years ago)
• Default Branch: develop
• Last Pushed: 2018-06-28T04:57:12.000Z (almost 7 years ago)
• Last Synced: 2025-02-05T14:39:31.729Z (4 months ago)
• Topics: eslint, eslint-config, javascript, linter, linter-config
• Language: JavaScript
• Homepage:
• Size: 38.1 KB
• Stars: 0
• Watchers: 1
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

        
# eslint-config-dhi

[![npm version](https://badge.fury.io/js/eslint-config-dhi.svg)](http://badge.fury.io/js/eslint-config-dhi)

This package provides DHI's .eslintrc as an extensible shared config.

It's a fork of Airbnb's eslint config, with DHI flavor.

### Getting started

Our default export contains all of our ESLint rules, including ECMAScript 6+.

Add this package as a dependency to your application:

```bash

npm i eslint-config-dhi -D # OR yarn add eslint-config-dhi -D

```

Add `{ "extends": ["eslint-config-dhi"] }` to your `.eslintrc.js`.

### Advanced

#### Using Babel

If your project uses ES6 or relies on babel features, the config should look something like this:

```javascript

module.exports = {

  "root": true,

  "parser": "babel-eslint",

  "extends": ["dhi"],

  "parserOptions": {

    "ecmaVersion": 8,

    "sourceType": "module",

    "ecmaFeatures": {

      "jsx": true,

      "experimentalObjectRestSpread": true

    }

  },

  "globals": {

    Polymer: true,

    Promise: true

  }

};

```

> Remember to install babel & babel-eslint. Using `@babel/preset-env` is recommended.

#### Using debugger in dev mode

If you want to use debugger statements during dev, you can turn it on in your .eslintrc.js file:

```javascript

...

  "rules": {

    "no-debugger": process.env.NODE_ENV === "production" ? 2: 0 // Allow debugger during development

  }

...

```

#### Using JSDoc

For projects that use JSDoc for documenting code, it might come in handy to use `eslint-plugin-jsdoc`. The recommended configuration to add to your project's .eslintrc is:

```javascript

  rules: {

    "jsdoc/check-param-names": 1,

    "jsdoc/check-types": 1,

    "jsdoc/newline-after-description": 1,

    "jsdoc/require-description-complete-sentence": 1,

    "jsdoc/require-param": 1,

    "jsdoc/require-param-name": 1,

    "jsdoc/require-param-type": 1,

    "jsdoc/require-returns-description": 1,

    "jsdoc/require-returns-type": 1

  },

  plugins: ['jsdoc']

```

#### Using with Prettier

If Prettier is used for style rules, then use the no-style variation of this plugin.

Add `{ "extends": ["eslint-config-dhi/no-style"] }` to your `.eslintrc.js`.

### Running tests

```

npm run test

```

### Modifying rules

Make a pull request with the rule that should be modified and why.

### Improving this config

Consider adding test cases if you're making complicated rules changes, like anything involving regexes. Perhaps in a distant future, we could use literate programming to structure our README as test cases for our .eslintrc?