tasks/server_copy.js

Summary

Maintainability

1 hr

Test Coverage

'module' is not defined.
Open

module.exports = function() {

Found in tasks/server_copy.js by eslint

Read up
Read up
Exclude checks
- Disable engine
- Disable check

Disallow Undeclared Variables (no-undef)

This rule can help you locate potential ReferenceErrors resulting from misspellings of variable and parameter names, or accidental implicit globals (for example, from forgetting the var keyword in a for loop initializer).

Rule Details

Any reference to an undeclared variable causes a warning, unless the variable is explicitly mentioned in a /*global ...*/ comment.

Examples of incorrect code for this rule:

/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

Examples of correct code for this rule with global declaration:

/*global someFunction b:true*/
/*eslint no-undef: "error"*/

var a = someFunction();
b = 10;

The b:true syntax in /*global */ indicates that assignment to b is correct.

Examples of incorrect code for this rule with global declaration:

/*global b*/
/*eslint no-undef: "error"*/

b = 10;

By default, variables declared in /*global */ are read-only, therefore assignment is incorrect.

Options

typeof set to true will warn for variables used inside typeof check (Default false).

typeof

Examples of correct code for the default { "typeof": false } option:

/*eslint no-undef: "error"*/

if (typeof UndefinedIdentifier === "undefined") {
    // do something ...
}

You can use this option if you want to prevent typeof check on a variable which has not been declared.

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

/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Examples of correct code for the { "typeof": true } option with global declaration:

/*global a*/
/*eslint no-undef: ["error", { "typeof": true }] */

if(typeof a === "string"){}

Environments

For convenience, ESLint provides shortcuts that pre-define global variables exposed by popular libraries and runtime environments. This rule supports these environments, as listed in Specifying Environments. A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

/*eslint no-undef: "error"*/
/*eslint-env browser*/

setTimeout(function() {
    alert("Hello");
});

node

Examples of correct code for this rule with node environment:

/*eslint no-undef: "error"*/
/*eslint-env node*/

var fs = require("fs");
module.exports = function() {
    console.log(fs);
};

When Not To Use It

If explicit declaration of global variables is not to your taste.

Compatibility

This rule provides compatibility with treatment of global variables in JSHint and JSLint.

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

Enforce or Disallow Semicolons (semi)

(fixable) The --fix option on the [command line](../user-guide/command-line-interface#fix) automatically fixes problems reported by this rule.

JavaScript is unique amongst the C-like languages in that it doesn't require semicolons at the end of each statement. In many cases, the JavaScript engine can determine that a semicolon should be in a certain spot and will automatically add it. This feature is known as automatic semicolon insertion (ASI) and is considered one of the more controversial features of JavaScript. For example, the following lines are both valid:

var name = "ESLint"
var website = "eslint.org";

On the first line, the JavaScript engine will automatically insert a semicolon, so this is not considered a syntax error. The JavaScript engine still knows how to interpret the line and knows that the line end indicates the end of the statement.

In the debate over ASI, there are generally two schools of thought. The first is that we should treat ASI as if it didn't exist and always include semicolons manually. The rationale is that it's easier to always include semicolons than to try to remember when they are or are not required, and thus decreases the possibility of introducing an error.

However, the ASI mechanism can sometimes be tricky to people who are using semicolons. For example, consider this code:

return
{
    name: "ESLint"
};

This may look like a return statement that returns an object literal, however, the JavaScript engine will interpret this code as:

return;
{
    name: "ESLint";
}

Effectively, a semicolon is inserted after the return statement, causing the code below it (a labeled literal inside a block) to be unreachable. This rule and the [no-unreachable](no-unreachable.md) rule will protect your code from such cases.

On the other side of the argument are those who says that since semicolons are inserted automatically, they are optional and do not need to be inserted manually. However, the ASI mechanism can also be tricky to people who don't use semicolons. For example, consider this code:

var globalCounter = { }

(function () {
    var n = 0
    globalCounter.increment = function () {
        return ++n
    }
})()

In this example, a semicolon will not be inserted after the first line, causing a run-time error (because an empty object is called as if it's a function). The [no-unexpected-multiline](no-unexpected-multiline.md) rule can protect your code from such cases.

Although ASI allows for more freedom over your coding style, it can also make your code behave in an unexpected way, whether you use semicolons or not. Therefore, it is best to know when ASI takes place and when it does not, and have ESLint protect your code from these potentially unexpected cases. In short, as once described by Isaac Schlueter, a \n character always ends a statement (just like a semicolon) unless one of the following is true:

The statement has an unclosed paren, array literal, or object literal or ends in some other way that is not a valid way to end a statement. (For instance, ending with . or ,.)
The line is -- or ++ (in which case it will decrement/increment the next token.)
It is a for(), while(), do, if(), or else, and there is no {
The next line starts with [, (, +, *, /, -, ,, ., or some other binary operator that can only be found between two tokens in a single expression.

Rule Details

This rule is aimed at ensuring consistent use of semicolons. You can decide whether or not to require semicolons at the end of statements.

Options

The rule takes one or two options. The first one is a string, which could be "always" or "never". The default is "always". The second one is an object for more fine-grained configuration when the first option is "always".

You can set the option in configuration like this:

"always"

By using the default option, semicolons must be used any place where they are valid.

semi: ["error", "always"]

The following patterns are considered problems:

/*eslint semi: "error"*/

var name = "ESLint"

object.method = function() {
    // ...
}

The following patterns are not considered problems:

/*eslint semi: "error"*/

var name = "ESLint";

object.method = function() {
    // ...
};

Fine-grained control

When setting the first option as "always", an additional option can be added to omit the last semicolon in a one-line block, that is, a block in which its braces (and therefore the content of the block) are in the same line:

semi: ["error", "always", { "omitLastInOneLineBlock": true}]

The following patterns are considered problems:

/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */

if (foo) {
    bar()
}

if (foo) { bar(); }

The following patterns are not considered problems:

/*eslint semi: ["error", "always", { "omitLastInOneLineBlock": true}] */

if (foo) { bar() }

if (foo) { bar(); baz() }

"never"

If you want to enforce that semicolons are never used, switch the configuration to:

semi: [2, "never"]

Then, the following patterns are considered problems:

/*eslint semi: ["error", "never"]*/

var name = "ESLint";

object.method = function() {
    // ...
};

And the following patterns are not considered problems:

/*eslint semi: ["error", "never"]*/

var name = "ESLint"

object.method = function() {
    // ...
}

Even in "never" mode, semicolons are still allowed to disambiguate statements beginning with [, (, /, +, or -:

/*eslint semi: ["error", "never"]*/

var name = "ESLint"

;(function() {
    // ...
})()

When Not To Use It

If you do not want to enforce semicolon usage (or omission) in any particular way, then you can turn this rule off.

Related Rules

[no-extra-semi](no-extra-semi.md)
[no-unexpected-multiline](no-unexpected-multiline.md)
[semi-spacing](semi-spacing.md) Source: http://eslint.org/docs/rules/

'use strict' is unnecessary inside of modules.
Open

'use strict';

Found in tasks/server_copy.js by eslint

Read up
Read up
Exclude checks
- Disable engine
- Disable check

Strict Mode Directives (strict)

A strict mode directive at the beginning of a script or function body enables strict mode semantics.

When used globally, the entire script, including all contained functions, are strict mode code:

"use strict";

It is also possible to specify function-level strict mode, such that strict mode applies only to the function in which the directive occurs:

function foo() {
    "use strict";
    return;
}

var bar = function() {
    "use strict";
    return;
};

Unlike scripts, ECMAScript modules are always in strict mode. Strict mode directives in ECMAScript modules have no effect.

Rule Details

This rule is aimed at using strict mode directives effectively, and as such, will flag any unexpected uses or omissions of strict mode directives.

Options

There are four options for this rule:

"safe" - require "use strict" globally when inside a module wrapper and in function scopes everywhere else. This is the default.
"never" - disallow "use strict".
"global" - require "use strict" in the global scope.
"function" - require "use strict" in function scopes only.

All strict mode directives are flagged as unnecessary if ECMAScript modules or implied strict mode are enabled (see [Specifying Parser Options](../user-guide/configuring#specifying-parser-options)). This behaviour does not depend on the rule options, but can be silenced by disabling this rule.

safe

Node.js and the CommonJS module system wrap modules inside a hidden function wrapper that defines each module's scope. The wrapper makes it safe to concatenate strict mode modules while maintaining their original strict mode directives. When the node or commonjs environments are enabled or globalReturn is enabled in ecmaFeatures, ESLint considers code to be inside the module wrapper, and "safe" mode corresponds to "global" mode and enforces global strict mode directives. Everywhere else, "safe" mode corresponds to "function" mode and enforces strict mode directives inside top-level functions.

never

This mode forbids any occurrence of a strict mode directive.

Examples of incorrect code for the "never" option:

/*eslint strict: ["error", "never"]*/

"use strict";

function foo() {
    "use strict";
    return;
}

var bar = function() {
    "use strict";
    return;
};

foo();
bar();

Examples of correct code for the "never" option:

/*eslint strict: ["error", "never"]*/

function foo() {
    return;
}

var bar = function() {
    return;
};

foo();
bar();

global

This mode ensures that all code is in strict mode and that there are no extraneous strict mode directives at the top level or in nested functions, which are themselves already strict by virtue of being contained in strict global code. It requires that global code contains exactly one strict mode directive. Strict mode directives inside functions are considered unnecessary. Multiple strict mode directives at any level also trigger warnings.

Examples of incorrect code for the "global" option:

/*eslint strict: ["error", "global"]*/

"use strict";
"use strict";

function foo() {
    "use strict";

    return function() {
        "use strict";
        "use strict";

        return;
    };
}

foo();

Examples of correct code for the "global" option:

/*eslint strict: ["error", "global"]*/

"use strict";

function foo() {
    return function() {
        return;
    };
}

foo();

function

This mode ensures that all function bodies are strict mode code, while global code is not. Particularly if a build step concatenates multiple scripts, a strict mode directive in global code of one script could unintentionally enable strict mode in another script that was not intended to be strict code. It forbids any occurrence of a strict mode directive in global code. It requires exactly one strict mode directive in each function declaration or expression whose parent is global code. Strict mode directives inside nested functions are considered unnecessary. Multiple strict mode directives at any level also trigger warnings.

Examples of incorrect code for the "function" option:

/*eslint strict: ["error", "function"]*/

"use strict";

function foo() {
    // Missing strict mode directive

    return function() {
        "use strict";   // Unnecessary; parent should contain a strict mode directive
        "use strict";

        return;
    };
}

foo();

Examples of correct code for the "function" option:

/*eslint strict: ["error", "function"]*/

function foo() {
    "use strict";

    return function() {
        return;
    };
}

(function() {
    "use strict";

    return;
}());

foo();

earlier default (removed)

Replacement notice: This mode, previously enabled by turning on the rule without specifying a mode, has been removed in ESLint v1.0. "function" mode is most similar to the deprecated behavior.

This mode ensures that all functions are executed in strict mode. A strict mode directive must be present in global code or in every top-level function declaration or expression. It does not concern itself with unnecessary strict mode directives in nested functions that are already strict, nor with multiple strict mode directives at the same level.

Examples of incorrect code for an earlier default option which has been removed:

// "strict": "error"

function foo() {
    return true;
}

Examples of correct code for an earlier default option which has been removed:

// "strict": "error"

"use strict";

function foo() {
    return true;
}

// "strict": "error"

function foo() {

    "use strict";

    return true;
}

// "strict": "error"

(function() {
    "use strict";

    // other code
}());

When Not To Use It

In a codebase that has both strict and non-strict code, either turn this rule off, or selectively disable it where necessary. For example, functions referencing arguments.callee are invalid in strict mode. A full list of strict mode differences is available on MDN. Source: http://eslint.org/docs/rules/

blacksonic/angular2-esnext-starter

Summary

Maintainability

Test Coverage

'module' is not defined. Open

Disallow Undeclared Variables (no-undef)

Rule Details

Options

typeof

Environments

browser

node

When Not To Use It

Compatibility

Further Reading

Identical blocks of code found in 2 locations. Consider refactoring. Open

Duplicated Code

Tuning

Refactorings

Further Reading

Missing semicolon. Open

Enforce or Disallow Semicolons (semi)

Rule Details

Options

"always"

Fine-grained control

"never"

When Not To Use It

Further Reading

Related Rules

'use strict' is unnecessary inside of modules. Open

Strict Mode Directives (strict)

Rule Details

Options

safe

never

global

function

earlier default (removed)

When Not To Use It

There are no issues that match your filters.

Category

Status

'module' is not defined.
Open

Identical blocks of code found in 2 locations. Consider refactoring.
Open

Missing semicolon.
Open

'use strict' is unnecessary inside of modules.
Open