eslint-config-dnode v1.11.0

Installation

npm i --save dexpress

Add a .eslintrc:

{
  "extends": "dnode"
}

Rules

class-methods-use-this

A method not using this can be static, yes, but I wouldn't force it. There can be reasons a method should be declared used with an instance (non static) independently if the method really use this or not.

comma-dangle

Trailing commas always if multiline. Exception for functions because node doesn't allow it.

consistent-return

A function without a return returns implicit undefined. So if I have one case which returns something and other cases which not, I don't write a return; or return undefined;.

bad

Use return; or return undefined; if nothing should be returned:

function example(example) {
  if (example === 'example') {
    return example;
  }
  return;
}

good

Just skip the unneeded returns and rely on the implicit return undefined:

function example(example) {
  if (example === 'example') {
    return example;
  }
}

global-require

I don't like to force the use of require in a global way. Sometimes its just shorter to use it inside a structure. Like inside an object for the lib.js.

bad

Define first const variables for all require:

const Example = require('./Example');

module.exports = {
  Example,
};

good

Just use require inside the object:

module.exports = {
  Example: require('./Example'),
};

import/newline-after-import

If using require it can be smart to chain and group the require together with other sequences.

bad

Using always new lines to separate require and another sequences:

const app = require('express')();

app.listen(process.env.PORT);

good

Group the lines by logically:

const app = require('express')();
app.listen(process.env.PORT);

import/no-dynamic-require

Dynamic require can not be analysed by static code analyser. But they allow a lot of convenient structures.

bad

Manually require all files statically into an object:

const examples = {
  a: require('./a'),
  b: require('./b'),
  c: require('./c'),
};
const example = 'a';
examples[example]();

good

Use dynamic require for a convenient structure:

const example = 'a';
require(`./${example}`)();

no-await-in-loop

Sometimes the async operations depending on each other in a loop. So its a legal use of await in a loop.

no-console

There isn't something bad in using console.log in node. 12factor say explicit logging should be done by stdout which is console.log.

no-lonely-if

Sometimes there is an else with a following if which is not depending to each other. In this cases its not usefull to transform this into an else if.

no-param-reassign

JavaScript doesn't have overloaded functions. So to define functions which allows multiple type of parameters I think reassign this parameter is a short and effective way to handle this.

bad

Define new variables:

function example(examples) {
  let checkedExamples = examples;
  if (!Array.isArray(checkedExamples)) {
    checkedExamples = [checkedExamples];
  }
}

good

Just reassign the parameters:

function example(examples) {
  if (!Array.isArray(examples)) {
    examples = [examples];
  }
}

no-restricted-syntax

JavaScript allow to iterate over arrays/objects with for ... in and for ... of. I want to use these keywords instead of functions like .forEach because its better readable.

bad

.forEach with arrow function:

examples.forEach(example => {

});

good

Use the native keywords of JavaScript:

for (const example of examples) {
  
}

no-shadow

It can make sense to use the same variables in different layers, especially for closures in array functions. But still care about the readability.

bad

Numerate or prefix variables:

const element = elements.map(element2 => element2.valid)[0];
// or
const element = elements.map(innerElement => innerElement.valid)[0];

good

Use the same variable names if the readability is still given:

const element = elements.map(element => element.valid)[0];

no-underscore-dangle

There is not a problem in using underscores in the beginning of a variable or function, especially if its not used to hint private or protected e.g. in translation function '__()'.