next();

Close

Enforce Return After Callback (callback-return)

The callback pattern is at the heart of most I/O and event-driven programming in JavaScript.

function doSomething(err, callback) {
    if (err) {
        return callback(err);
    }
    callback();
}

To prevent calling the callback multiple times it is important to return anytime the callback is triggered outside of the main function body. Neglecting this technique often leads to issues where you do something more than once. For example, in the case of an HTTP request, you may try to send HTTP headers more than once leading Node.js to throw a Can't render headers after they are sent to the client. error.

Rule Details

This rule is aimed at ensuring that callbacks used outside of the main function block are always part-of or immediately preceding a return statement. This rule decides what is a callback based on the name of the function being called.

Options

The rule takes a single option - an array of possible callback names - which may include object methods. The default callback names are callback, cb, next.

Default callback names

Examples of incorrect code for this rule with the default ["callback", "cb", "next"] option:

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

function foo(err, callback) {
    if (err) {
        callback(err);
    }
    callback();
}

Examples of correct code for this rule with the default ["callback", "cb", "next"] option:

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

function foo(err, callback) {
    if (err) {
        return callback(err);
    }
    callback();
}

Supplied callback names

Examples of incorrect code for this rule with the option ["done", "send.error", "send.success"]:

/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/

function foo(err, done) {
    if (err) {
        done(err);
    }
    done();
}

function bar(err, send) {
    if (err) {
        send.error(err);
    }
    send.success();
}

Examples of correct code for this rule with the option ["done", "send.error", "send.success"]:

/*eslint callback-return: ["error", ["done", "send.error", "send.success"]]*/

function foo(err, done) {
    if (err) {
        return done(err);
    }
    done();
}

function bar(err, send) {
    if (err) {
        return send.error(err);
    }
    send.success();
}

Known Limitations

Because it is difficult to understand the meaning of a program through static analysis, this rule has limitations:

• false negatives when this rule reports correct code, but the program calls the callback more than one time (which is incorrect behavior)
• false positives when this rule reports incorrect code, but the program calls the callback only one time (which is correct behavior)

Passing the callback by reference

The static analysis of this rule does not detect that the program calls the callback if it is an argument of a function (for example, setTimeout).

Example of a false negative when this rule reports correct code:

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

function foo(err, callback) {
    if (err) {
        setTimeout(callback, 0); // this is bad, but WILL NOT warn
    }
    callback();
}

Triggering the callback within a nested function

The static analysis of this rule does not detect that the program calls the callback from within a nested function or an immediately-invoked function expression (IIFE).

Example of a false negative when this rule reports correct code:

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

function foo(err, callback) {
    if (err) {
        process.nextTick(function() {
            return callback(); // this is bad, but WILL NOT warn
        });
    }
    callback();
}

If/else statements

The static analysis of this rule does not detect that the program calls the callback only one time in each branch of an if statement.

Example of a false positive when this rule reports incorrect code:

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

function foo(err, callback) {
    if (err) {
        callback(err); // this is fine, but WILL warn
    } else {
        callback();    // this is fine, but WILL warn
    }
}

When Not To Use It

There are some cases where you might want to call a callback function more than once. In those cases this rule may lead to incorrect behavior. In those cases you may want to reserve a special name for those callbacks and not include that in the list of callbacks that trigger warnings.

Further Reading

• The Art Of Node: Callbacks
• Nodejitsu: What are the error conventions?

Related Rules

• [handle-callback-err](handle-callback-err.md) Source: http://eslint.org/docs/rules/

          walk(file, function (err, res) {

Close

Enforce Callback Error Handling (handle-callback-err)

In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern. This pattern expects an Error object or null as the first argument of the callback. Forgetting to handle these errors can lead to some really strange behavior in your application.

function loadData (err, data) {
    doSomething(); // forgot to handle error
}

Rule Details

This rule expects that when you're using the callback pattern in Node.js you'll handle the error.

Options

The rule takes a single string option: the name of the error parameter. The default is "err".

Examples of incorrect code for this rule with the default "err" parameter name:

/*eslint handle-callback-err: "error"*/

function loadData (err, data) {
    doSomething();
}

Examples of correct code for this rule with the default "err" parameter name:

/*eslint handle-callback-err: "error"*/

function loadData (err, data) {
    if (err) {
        console.log(err.stack);
    }
    doSomething();
}

function generateError (err) {
    if (err) {}
}

Examples of correct code for this rule with a sample "error" parameter name:

/*eslint handle-callback-err: ["error", "error"]*/

function loadData (error, data) {
    if (error) {
       console.log(error.stack);
    }
    doSomething();
}

regular expression

Sometimes (especially in big projects) the name of the error variable is not consistent across the project, so you need a more flexible configuration to ensure that the rule reports all unhandled errors.

If the configured name of the error variable begins with a ^ it is considered to be a regexp pattern.

• If the option is "^(err|error|anySpecificError)$", the rule reports unhandled errors where the parameter name can be err, error or anySpecificError.
• If the option is "^.+Error$", the rule reports unhandled errors where the parameter name ends with Error (for example, connectionError or validationError will match).
• If the option is "^.*(e|E)rr", the rule reports unhandled errors where the parameter name matches any string that contains err or Err (for example, err, error, anyError, some_err will match).

When Not To Use It

There are cases where it may be safe for your application to ignore errors, however only ignore errors if you are confident that some other form of monitoring will help you catch the problem.

Further Reading

• The Art Of Node: Callbacks
• Nodejitsu: What are the error conventions? Source: http://eslint.org/docs/rules/

      fs.stat(file, function (err, stat) {

Close

Enforce Callback Error Handling (handle-callback-err)

In Node.js, a common pattern for dealing with asynchronous behavior is called the callback pattern. This pattern expects an Error object or null as the first argument of the callback. Forgetting to handle these errors can lead to some really strange behavior in your application.

function loadData (err, data) {
    doSomething(); // forgot to handle error
}

Rule Details

This rule expects that when you're using the callback pattern in Node.js you'll handle the error.

Options

The rule takes a single string option: the name of the error parameter. The default is "err".

Examples of incorrect code for this rule with the default "err" parameter name:

/*eslint handle-callback-err: "error"*/

function loadData (err, data) {
    doSomething();
}

Examples of correct code for this rule with the default "err" parameter name:

/*eslint handle-callback-err: "error"*/

function loadData (err, data) {
    if (err) {
        console.log(err.stack);
    }
    doSomething();
}

function generateError (err) {
    if (err) {}
}

Examples of correct code for this rule with a sample "error" parameter name:

/*eslint handle-callback-err: ["error", "error"]*/

function loadData (error, data) {
    if (error) {
       console.log(error.stack);
    }
    doSomething();
}

regular expression

Sometimes (especially in big projects) the name of the error variable is not consistent across the project, so you need a more flexible configuration to ensure that the rule reports all unhandled errors.

If the configured name of the error variable begins with a ^ it is considered to be a regexp pattern.

• If the option is "^(err|error|anySpecificError)$", the rule reports unhandled errors where the parameter name can be err, error or anySpecificError.
• If the option is "^.+Error$", the rule reports unhandled errors where the parameter name ends with Error (for example, connectionError or validationError will match).
• If the option is "^.*(e|E)rr", the rule reports unhandled errors where the parameter name matches any string that contains err or Err (for example, err, error, anyError, some_err will match).

When Not To Use It

There are cases where it may be safe for your application to ignore errors, however only ignore errors if you are confident that some other form of monitoring will help you catch the problem.

Further Reading

• The Art Of Node: Callbacks
• Nodejitsu: What are the error conventions? Source: http://eslint.org/docs/rules/

    (function next() {

Close

Require IIFEs to be Wrapped (wrap-iife)

You can immediately invoke function expressions, but not function declarations. A common technique to create an immediately-invoked function expression (IIFE) is to wrap a function declaration in parentheses. The opening parentheses causes the contained function to be parsed as an expression, rather than a declaration.

// function expression could be unwrapped
var x = function () { return { y: 1 };}();

// function declaration must be wrapped
function () { /* side effects */ }(); // SyntaxError

Rule Details

This rule requires all immediately-invoked function expressions to be wrapped in parentheses.

Options

This rule has two options, a string option and an object option.

String option:

• "outside" enforces always wrapping the call expression. The default is "outside".
• "inside" enforces always wrapping the function expression.
• "any" enforces always wrapping, but allows either style.

Object option:

• "functionPrototypeMethods": true additionally enforces wrapping function expressions invoked using .call and .apply. The default is false.

outside

Examples of incorrect code for the default "outside" option:

/*eslint wrap-iife: ["error", "outside"]*/

var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };})(); // wrapped function expression

Examples of correct code for the default "outside" option:

/*eslint wrap-iife: ["error", "outside"]*/

var x = (function () { return { y: 1 };}()); // wrapped call expression

inside

Examples of incorrect code for the "inside" option:

/*eslint wrap-iife: ["error", "inside"]*/

var x = function () { return { y: 1 };}(); // unwrapped
var x = (function () { return { y: 1 };}()); // wrapped call expression

Examples of correct code for the "inside" option:

/*eslint wrap-iife: ["error", "inside"]*/

var x = (function () { return { y: 1 };})(); // wrapped function expression

any

Examples of incorrect code for the "any" option:

/*eslint wrap-iife: ["error", "any"]*/

var x = function () { return { y: 1 };}(); // unwrapped

Examples of correct code for the "any" option:

/*eslint wrap-iife: ["error", "any"]*/

var x = (function () { return { y: 1 };}()); // wrapped call expression
var x = (function () { return { y: 1 };})(); // wrapped function expression

functionPrototypeMethods

Examples of incorrect code for this rule with the "inside", { "functionPrototypeMethods": true } options:

/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */

var x = function(){ foo(); }()
var x = (function(){ foo(); }())
var x = function(){ foo(); }.call(bar)
var x = (function(){ foo(); }.call(bar))

Examples of correct code for this rule with the "inside", { "functionPrototypeMethods": true } options:

/* eslint wrap-iife: [2, "inside", { functionPrototypeMethods: true }] */

var x = (function(){ foo(); })()
var x = (function(){ foo(); }).call(bar)

Source: http://eslint.org/docs/rules/