Sign upLogin

thegameofcode/cipherlayer

View on GitHub
Star
src/managers/user.js

Summary

Maintainability
F
4 days
Test Coverage

File user.js has 479 lines of code (exceeds 250 allowed). Consider refactoring.
Open

'use strict';

const request = require('request');
const _ = require('lodash');
const ciphertoken = require('ciphertoken');
Severity: Minor
Found in src/managers/user.js - About 7 hrs to fix

    Function createUserPrivateCall has 117 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

    function createUserPrivateCall(body, user, cbk) {
    const clonedBody = _.clone(body);
    delete clonedBody.password;
    const options = {
        url: `http://${_settings.private_host}:${_settings.private_port}${_settings.passThroughEndpoint.path}`,
    Severity: Major
    Found in src/managers/user.js - About 4 hrs to fix

      Function createUserByToken has 101 lines of code (exceeds 25 allowed). Consider refactoring.
      Open

      function createUserByToken(token, cbk) {
    if (!token) {
        return cbk({
            err: 'auth_proxy_error',
            des: 'empty param verifyToken',
      Severity: Major
      Found in src/managers/user.js - About 4 hrs to fix

        Function createUser has 98 lines of code (exceeds 25 allowed). Consider refactoring.
        Open

        function createUser(body, pin, cbk) {
    if (!body[_settings.passThroughEndpoint.username]) {
        return cbk({
            err: 'auth_proxy_error',
            des: 'invalid userinfo',
        Severity: Major
        Found in src/managers/user.js - About 3 hrs to fix

          Function isValidDomain has 32 lines of code (exceeds 25 allowed). Consider refactoring.
          Open

          function isValidDomain(email, cbk) {
    // settings overrides realms configuration
    if (_settings.allowedDomains) {
        for (let i = 0; i < _settings.allowedDomains.length; i++) {
            const domain = _settings.allowedDomains[i];
          Severity: Minor
          Found in src/managers/user.js - About 1 hr to fix

            Function addRealmToUser has 30 lines of code (exceeds 25 allowed). Consider refactoring.
            Open

            function addRealmToUser(userId, name, cbk) {
    async.waterfall([
        function (done) {
            daoMng.getRealmFromName(name, function (err, realm) {
                if (err) {
            Severity: Minor
            Found in src/managers/user.js - About 1 hr to fix

              Function isValidDomain has a Cognitive Complexity of 7 (exceeds 5 allowed). Consider refactoring.
              Open

              function isValidDomain(email, cbk) {
    // settings overrides realms configuration
    if (_settings.allowedDomains) {
        for (let i = 0; i < _settings.allowedDomains.length; i++) {
            const domain = _settings.allowedDomains[i];
              Severity: Minor
              Found in src/managers/user.js - About 35 mins to fix

              Cognitive Complexity

              Cognitive Complexity is a measure of how difficult a unit of code is to intuitively understand. Unlike Cyclomatic Complexity, which determines how difficult your code will be to test, Cognitive Complexity tells you how difficult your code will be to read and comprehend.

              A method's cognitive complexity is based on a few simple rules:

              • Code is not considered more complex when it uses shorthand that the language provides for collapsing multiple statements into one
              • Code is considered more complex for each "break in the linear flow of the code"
              • Code is considered more complex when "flow breaking structures are nested"

              Further reading

              Expected to return a value at the end of function.
              Open

                          phoneMng(_settings).verifyPhone(user.username, phone, countryISO, pin, function (err) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                      daoMng.getFromUsername(user.username, function (err, foundUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                      redisMng.getKeyValue(redisKey, function (err, transactionId) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function 'createUserByToken'.
              Open

              function createUserByToken(token, cbk) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                              daoMng.getFromUsername(user.username, function (err, foundUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                  daoMng.getAllUserFields(username, function (err, user) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'err' is already declared in the upper scope.
              Open

                              daoMng.getFromUsername(user.username, function (err, foundUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              'err' is already declared in the upper scope.
              Open

                          daoMng.addUser(user, function (err, createdUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              'err' is already declared in the upper scope.
              Open

                                          daoMng.getRealms(function (err, realms) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Expected to return a value at the end of function.
              Open

                  request(options, function (err, private_res, body) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function 'isValidDomain'.
              Open

              function isValidDomain(email, cbk) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'err' is already declared in the upper scope.
              Open

                          phoneMng(_settings).verifyPhone(user.username, phone, countryISO, pin, function (err) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              'err' is already declared in the upper scope.
              Open

                              daoMng.getFromUsernamePassword(createdUser.username, createdUser.password, function (err, foundUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Expected to return a value at the end of function.
              Open

                  ciphertoken.getTokenSet(tokenSettings, token, function (err, bodyData) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                          daoMng.addUser(user, function (err, createdUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'err' is already declared in the upper scope.
              Open

                                  emailMng(_settings).emailVerification(body[_settings.passThroughEndpoint.email || 'email'], body, function (err, destinationEmail) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Expected to return a value at the end of function.
              Open

                                          daoMng.getRealms(function (err, realms) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                                              async.eachSeries(realms, function (realm, next) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                          isValidDomain(user.username, function (isValid) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function.
              Open

                                                  async.eachSeries(realm.allowedDomains, function (domain, more) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function 'setPassword'.
              Open

              function setPassword(id, body, cbk) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              Expected to return a value at the end of function 'createUser'.
              Open

              function createUser(body, pin, cbk) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'err' is already declared in the upper scope.
              Open

                                  tokenMng.getAccessTokenInfo(body.sf, function (err, tokenInfo) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              'err' is already declared in the upper scope.
              Open

                      redisMng.getKeyValue(redisKey, function (err, transactionId) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Function expected a return value.
              Open

                              return;
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'err' is already declared in the upper scope.
              Open

                                      tokenMng.createBothTokens(foundUser._id, data, function (err, tokens) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              'err' is already declared in the upper scope.
              Open

                                          tokenMng.createBothTokens(foundUser._id, data, function (err, tokens) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Expected to return a value at the end of function.
              Open

                              daoMng.getFromUsernamePassword(createdUser.username, createdUser.password, function (err, foundUser) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'body' is already declared in the upper scope.
              Open

                  request(options, function (err, private_res, body) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              disallow variable declarations from shadowing variables declared in the outer scope (no-shadow)

              Shadowing is the process by which a local variable shares the same name as a variable in its containing scope. For example:

              var a = 3;
function b() {
    var a = 10;
}

              In this case, the variable a inside of b() is shadowing the variable a in the global scope. This can cause confusion while reading the code and it's impossible to access the global variable.

              Rule Details

              This rule aims to eliminate shadowed variable declarations.

              Examples of incorrect code for this rule:

              /*eslint no-shadow: "error"*/
/*eslint-env es6*/

var a = 3;
function b() {
    var a = 10;
}

var b = function () {
    var a = 10;
}

function b(a) {
    a = 10;
}
b(a);

if (true) {
    let a = 5;
}

              Options

              This rule takes one option, an object, with properties "builtinGlobals", "hoist" and "allow".

              {
    "no-shadow": ["error", { "builtinGlobals": false, "hoist": "functions", "allow": [] }]
}

              builtinGlobals

              The builtinGlobals option is false by default. If it is true, the rule prevents shadowing of built-in global variables: Object, Array, Number, and so on.

              Examples of incorrect code for the { "builtinGlobals": true } option:

              /*eslint no-shadow: ["error", { "builtinGlobals": true }]*/

function foo() {
    var Object = 0;
}

              hoist

              The hoist option has three settings:

              • functions (by default) - reports shadowing before the outer functions are defined.
              • all - reports all shadowing before the outer variables/functions are defined.
              • never - never report shadowing before the outer variables/functions are defined.

              hoist: functions

              Examples of incorrect code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let b = 6;
}

function b() {}

              Although let b in the if statement is before the function declaration in the outer scope, it is incorrect.

              Examples of correct code for the default { "hoist": "functions" } option:

              /*eslint no-shadow: ["error", { "hoist": "functions" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
}

let a = 5;

              Because let a in the if statement is before the variable declaration in the outer scope, it is correct.

              hoist: all

              Examples of incorrect code for the { "hoist": "all" } option:

              /*eslint no-shadow: ["error", { "hoist": "all" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              hoist: never

              Examples of correct code for the { "hoist": "never" } option:

              /*eslint no-shadow: ["error", { "hoist": "never" }]*/
/*eslint-env es6*/

if (true) {
    let a = 3;
    let b = 6;
}

let a = 5;
function b() {}

              Because let a and let b in the if statement are before the declarations in the outer scope, they are correct.

              allow

              The allow option is an array of identifier names for which shadowing is allowed. For example, "resolve", "reject", "done", "cb".

              Examples of correct code for the { "allow": ["done"] } option:

              /*eslint no-shadow: ["error", { "allow": ["done"] }]*/
/*eslint-env es6*/

import async from 'async';

function foo(done) {
  async.map([1, 2], function (e, done) {
    done(null, e * 2)
  }, done);
}

foo(function (err, result) {
  console.log({ err, result });
});

              Further Reading

              Related Rules

              Expected to return a value at the end of function.
              Open

                  isValidDomain(body[_settings.passThroughEndpoint.username], function (isValid) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              require return statements to either always or never specify values (consistent-return)

              Unlike statically-typed languages which enforce that a function returns a specified type of value, JavaScript allows different code paths in a function to return different types of values.

              A confusing aspect of JavaScript is that a function returns undefined if any of the following are true:

              • it does not execute a return statement before it exits
              • it executes return which does not specify a value explicitly
              • it executes return undefined
              • it executes return void followed by an expression (for example, a function call)
              • it executes return followed by any other expression which evaluates to undefined

              If any code paths in a function return a value explicitly but some code path do not return a value explicitly, it might be a typing mistake, especially in a large function. In the following example:

              • a code path through the function returns a Boolean value true
              • another code path does not return a value explicitly, therefore returns undefined implicitly
              function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

              Rule Details

              This rule requires return statements to either always or never specify values. This rule ignores function definitions where the name begins with an uppercase letter, because constructors (when invoked with the new operator) return the instantiated object implicitly if they do not return another object explicitly.

              Examples of incorrect code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return;
    }
}

function doSomething(condition) {
    if (condition) {
        return true;
    }
}

              Examples of correct code for this rule:

              /*eslint consistent-return: "error"*/

function doSomething(condition) {
    if (condition) {
        return true;
    } else {
        return false;
    }
}

function Foo() {
    if (!(this instanceof Foo)) {
        return new Foo();
    }

    this.a = 0;
}

              Options

              This rule has an object option:

              • "treatUndefinedAsUnspecified": false (default) always either specify values or return undefined implicitly only.
              • "treatUndefinedAsUnspecified": true always either specify values or return undefined explicitly or implicitly.

              treatUndefinedAsUnspecified

              Examples of incorrect code for this rule with the default { "treatUndefinedAsUnspecified": false } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": false }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              Examples of incorrect code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    return true;
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    return true;
}

              Examples of correct code for this rule with the { "treatUndefinedAsUnspecified": true } option:

              /*eslint consistent-return: ["error", { "treatUndefinedAsUnspecified": true }]*/

function foo(callback) {
    if (callback) {
        return void callback();
    }
    // no return statement
}

function bar(condition) {
    if (condition) {
        return undefined;
    }
    // no return statement
}

              When Not To Use It

              If you want to allow functions to have different return behavior depending on code branching, then it is safe to disable this rule. Source: http://eslint.org/docs/rules/

              'i' is never reassigned. Use 'const' instead.
              Open

                      for (let i in realms) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              Suggest using const (prefer-const)

              If a variable is never reassigned, using the const declaration is better.

              const declaration tells readers, "this variable is never reassigned," reducing cognitive load and improving maintainability.

              Rule Details

              This rule is aimed at flagging variables that are declared using let keyword, but never reassigned after the initial assignment.

              Examples of incorrect code for this rule:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// it's initialized and never reassigned.
let a = 3;
console.log(a);

let a;
a = 0;
console.log(a);

// `i` is redefined (not reassigned) on each loop step.
for (let i in [1, 2, 3]) {
    console.log(i);
}

// `a` is redefined (not reassigned) on each loop step.
for (let a of [1, 2, 3]) {
    console.log(a);
}

              Examples of correct code for this rule:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const a = 0;

// it's never initialized.
let a;
console.log(a);

// it's reassigned after initialized.
let a;
a = 0;
a = 1;
console.log(a);

// it's initialized in a different block from the declaration.
let a;
if (true) {
    a = 0;
}
console.log(a);

// it's initialized at a place that we cannot write a variable declaration.
let a;
if (true) a = 0;
console.log(a);

// `i` gets a new binding each iteration
for (const i in [1, 2, 3]) {
  console.log(i);
}

// `a` gets a new binding each iteration
for (const a of [1, 2, 3]) {
  console.log(a);
}

// `end` is never reassigned, but we cannot separate the declarations without modifying the scope.
for (let i = 0, end = 10; i < end; ++i) {
    console.log(a);
}

// suggest to use `no-var` rule.
var b = 3;
console.log(b);

              Options

              {
    "prefer-const": ["error", {
        "destructuring": "any",
        "ignoreReadBeforeAssign": false
    }]
}

              destructuring

              The kind of the way to address variables in destructuring. There are 2 values:

              • "any" (default) - If any variables in destructuring should be const, this rule warns for those variables.
              • "all" - If all variables in destructuring should be const, this rule warns the variables. Otherwise, ignores them.

              Examples of incorrect code for the default {"destructuring": "any"} option:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

let {a, b} = obj;    /*error 'b' is never reassigned, use 'const' instead.*/
a = a + 1;

              Examples of correct code for the default {"destructuring": "any"} option:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const {a: a0, b} = obj;
const a = a0 + 1;

// all variables are reassigned.
let {a, b} = obj;
a = a + 1;
b = b + 1;

              Examples of incorrect code for the {"destructuring": "all"} option:

              /*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// all of `a` and `b` should be const, so those are warned.
let {a, b} = obj;    /*error 'a' is never reassigned, use 'const' instead.
                             'b' is never reassigned, use 'const' instead.*/

              Examples of correct code for the {"destructuring": "all"} option:

              /*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// 'b' is never reassigned, but all of `a` and `b` should not be const, so those are ignored.
let {a, b} = obj;
a = a + 1;

              ignoreReadBeforeAssign

              This is an option to avoid conflicting with no-use-before-define rule (without "nofunc" option). If true is specified, this rule will ignore variables that are read between the declaration and the first assignment. Default is false.

              Examples of correct code for the {"ignoreReadBeforeAssign": true} option:

              /*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": true}]*/
/*eslint-env es6*/

let timer;
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}
timer = setInterval(initialize, 100);

              Examples of correct code for the default {"ignoreReadBeforeAssign": false} option:

              /*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": false}]*/
/*eslint-env es6*/

const timer = setInterval(initialize, 100);
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}

              When Not To Use It

              If you don't want to be notified about variables that are never reassigned after initial assignment, you can safely disable this rule.

              Related Rules

              'j' is never reassigned. Use 'const' instead.
              Open

                          for (let j in realm.allowedDomains) {
              Severity: Minor
              Found in src/managers/user.js by eslint

              Suggest using const (prefer-const)

              If a variable is never reassigned, using the const declaration is better.

              const declaration tells readers, "this variable is never reassigned," reducing cognitive load and improving maintainability.

              Rule Details

              This rule is aimed at flagging variables that are declared using let keyword, but never reassigned after the initial assignment.

              Examples of incorrect code for this rule:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// it's initialized and never reassigned.
let a = 3;
console.log(a);

let a;
a = 0;
console.log(a);

// `i` is redefined (not reassigned) on each loop step.
for (let i in [1, 2, 3]) {
    console.log(i);
}

// `a` is redefined (not reassigned) on each loop step.
for (let a of [1, 2, 3]) {
    console.log(a);
}

              Examples of correct code for this rule:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const a = 0;

// it's never initialized.
let a;
console.log(a);

// it's reassigned after initialized.
let a;
a = 0;
a = 1;
console.log(a);

// it's initialized in a different block from the declaration.
let a;
if (true) {
    a = 0;
}
console.log(a);

// it's initialized at a place that we cannot write a variable declaration.
let a;
if (true) a = 0;
console.log(a);

// `i` gets a new binding each iteration
for (const i in [1, 2, 3]) {
  console.log(i);
}

// `a` gets a new binding each iteration
for (const a of [1, 2, 3]) {
  console.log(a);
}

// `end` is never reassigned, but we cannot separate the declarations without modifying the scope.
for (let i = 0, end = 10; i < end; ++i) {
    console.log(a);
}

// suggest to use `no-var` rule.
var b = 3;
console.log(b);

              Options

              {
    "prefer-const": ["error", {
        "destructuring": "any",
        "ignoreReadBeforeAssign": false
    }]
}

              destructuring

              The kind of the way to address variables in destructuring. There are 2 values:

              • "any" (default) - If any variables in destructuring should be const, this rule warns for those variables.
              • "all" - If all variables in destructuring should be const, this rule warns the variables. Otherwise, ignores them.

              Examples of incorrect code for the default {"destructuring": "any"} option:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

let {a, b} = obj;    /*error 'b' is never reassigned, use 'const' instead.*/
a = a + 1;

              Examples of correct code for the default {"destructuring": "any"} option:

              /*eslint prefer-const: "error"*/
/*eslint-env es6*/

// using const.
const {a: a0, b} = obj;
const a = a0 + 1;

// all variables are reassigned.
let {a, b} = obj;
a = a + 1;
b = b + 1;

              Examples of incorrect code for the {"destructuring": "all"} option:

              /*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// all of `a` and `b` should be const, so those are warned.
let {a, b} = obj;    /*error 'a' is never reassigned, use 'const' instead.
                             'b' is never reassigned, use 'const' instead.*/

              Examples of correct code for the {"destructuring": "all"} option:

              /*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// 'b' is never reassigned, but all of `a` and `b` should not be const, so those are ignored.
let {a, b} = obj;
a = a + 1;

              ignoreReadBeforeAssign

              This is an option to avoid conflicting with no-use-before-define rule (without "nofunc" option). If true is specified, this rule will ignore variables that are read between the declaration and the first assignment. Default is false.

              Examples of correct code for the {"ignoreReadBeforeAssign": true} option:

              /*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": true}]*/
/*eslint-env es6*/

let timer;
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}
timer = setInterval(initialize, 100);

              Examples of correct code for the default {"ignoreReadBeforeAssign": false} option:

              /*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": false}]*/
/*eslint-env es6*/

const timer = setInterval(initialize, 100);
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}

              When Not To Use It

              If you don't want to be notified about variables that are never reassigned after initial assignment, you can safely disable this rule.

              Related Rules

              Identical blocks of code found in 2 locations. Consider refactoring.
              Open

                                          tokenMng.createBothTokens(foundUser._id, data, function (err, tokens) {
                                if (err) {
                                    log.error({err}, 'error creating tokens');
                                    return cbk({
                                        err: err.message,
              Severity: Major
              Found in src/managers/user.js and 1 other location - About 3 hrs to fix
              src/managers/user.js on lines 395..405

              Duplicated Code

              Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

              Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

              When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

              Tuning

              This issue has a mass of 102.

              We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

              The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

              If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

              See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

              Refactorings

              Further Reading

              Identical blocks of code found in 2 locations. Consider refactoring.
              Open

                                      tokenMng.createBothTokens(foundUser._id, data, function (err, tokens) {
                            if (err) {
                                log.error({err}, 'error creating tokens');
                                return cbk({
                                    err: err.message,
              Severity: Major
              Found in src/managers/user.js and 1 other location - About 3 hrs to fix
              src/managers/user.js on lines 248..258

              Duplicated Code

              Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

              Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

              When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

              Tuning

              This issue has a mass of 102.

              We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

              The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

              If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

              See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

              Refactorings

              Further Reading

              Similar blocks of code found in 2 locations. Consider refactoring.
              Open

                          if (!validatePwd(body.password, _settings.password.regexValidation)) {
                const invalidPasswordError = ERR_INVALID_PWD;
                invalidPasswordError.des = _settings.password.message;
                return cbk(invalidPasswordError);
            }
              Severity: Major
              Found in src/managers/user.js and 1 other location - About 1 hr to fix
              src/managers/user.js on lines 424..428

              Duplicated Code

              Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

              Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

              When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

              Tuning

              This issue has a mass of 59.

              We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

              The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

              If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

              See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

              Refactorings

              Further Reading

              Similar blocks of code found in 2 locations. Consider refactoring.
              Open

                  if (!validatePwd(body.password, _settings.password.regexValidation)) {
        const err = ERR_INVALID_PWD;
        err.des = _settings.password.message;
        return cbk(err);
    }
              Severity: Major
              Found in src/managers/user.js and 1 other location - About 1 hr to fix
              src/managers/user.js on lines 74..78

              Duplicated Code

              Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

              Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

              When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

              Tuning

              This issue has a mass of 59.

              We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

              The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

              If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

              See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

              Refactorings

              Further Reading

              Definition for rule 'extra-rules/no-for-loops' was not found
              Open

              'use strict';
              Severity: Minor
              Found in src/managers/user.js by eslint

              For more information visit Source: http://eslint.org/docs/rules/

              Definition for rule 'extra-rules/potential-point-free' was not found
              Open

              'use strict';
              Severity: Minor
              Found in src/managers/user.js by eslint

              For more information visit Source: http://eslint.org/docs/rules/

              There are no issues that match your filters.

              Category
              Status