blacksonic/angular2-esnext-starter

View on GitHub

Showing 111 of 111 total issues

Function exports has a Cognitive Complexity of 17 (exceeds 5 allowed). Consider refactoring.
Open

module.exports = function(singleRun, callback) {
  return function(cb) {
    let webpackConfig = singleRun ? require('./config/webpack.dist') : require('./config/webpack');
    let webpackBuild = webpack(webpackConfig);
    let firstRun = true;
Severity: Minor
Found in tasks/client_build.js - About 2 hrs 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

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

  onSave(post) {
    this._postService.addPost(post).subscribe(
      () => {
        this._router.navigate(['']);
      },
Severity: Major
Found in client/app/posts/components/post-new/post-new.component.js and 1 other location - About 1 hr to fix
client/app/posts/components/post-edit/post-edit.component.js on lines 25..34

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 72.

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

  onSave(post) {
    this._postService.updatePost(post).subscribe(
      () => {
        this._router.navigate(['']);
      },
client/app/posts/components/post-new/post-new.component.js on lines 17..26

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 72.

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

Function exports has 38 lines of code (exceeds 25 allowed). Consider refactoring.
Open

module.exports = function(singleRun, callback) {
  return function(cb) {
    let webpackConfig = singleRun ? require('./config/webpack.dist') : require('./config/webpack');
    let webpackBuild = webpack(webpackConfig);
    let firstRun = true;
Severity: Minor
Found in tasks/client_build.js - About 1 hr to fix

    Function exports has 38 lines of code (exceeds 25 allowed). Consider refactoring.
    Open

    module.exports = function(config) {
      let webpackConfig = require('./webpack.test');
      let reporters = ['dots'];
      if (coverageEnabled) {
        reporters.push('coverage');
    Severity: Minor
    Found in tasks/config/karma.js - About 1 hr to fix

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

          service.updatePost(singlePost).subscribe((post) => {
            expect(post).toEqual(singlePost);
            expect(RequestService.prototype.getAuthHeaders).toHaveBeenCalled();
          });
      Severity: Major
      Found in client/app/posts/services/post/post.service.spec.js and 1 other location - About 1 hr to fix
      client/app/posts/services/post/post.service.spec.js on lines 101..104

      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 62.

      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

          service.addPost(singlePost).subscribe((post) => {
            expect(post).toEqual(singlePost);
            expect(RequestService.prototype.getAuthHeaders).toHaveBeenCalled();
          });
      Severity: Major
      Found in client/app/posts/services/post/post.service.spec.js and 1 other location - About 1 hr to fix
      client/app/posts/services/post/post.service.spec.js on lines 112..115

      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 62.

      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

      module.exports = function() {
        return function() {
          return gulp.src(config.source)
            .pipe(gulp.dest(config.destination));
        }
      Severity: Major
      Found in tasks/server_copy.js and 1 other location - About 1 hr to fix
      tasks/general_copy.js on lines 5..10

      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

          return this._http
            .post('/post', JSON.stringify(post), { headers: this._request.getAuthHeaders() })
            .map(res => res.json());
      Severity: Major
      Found in client/app/posts/services/post/post.service.js and 1 other location - About 1 hr to fix
      client/app/auth/services/user/user.service.js on lines 24..26

      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

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

      module.exports = function() {
        return function() {
          return gulp.src(config.source)
            .pipe(gulp.dest(config.destination));
        }
      Severity: Major
      Found in tasks/general_copy.js and 1 other location - About 1 hr to fix
      tasks/server_copy.js on lines 5..10

      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

          return this._http
            .post('/login', JSON.stringify(credentials), { headers: this._request.getJsonHeaders() })
            .map(res => res.json())
      Severity: Major
      Found in client/app/auth/services/user/user.service.js and 1 other location - About 1 hr to fix
      client/app/posts/services/post/post.service.js on lines 33..35

      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

      Function returnsResponse has 5 arguments (exceeds 4 allowed). Consider refactoring.
      Open

        function returnsResponse(response, method, url, body, headers) {
      Severity: Minor
      Found in client/app/posts/services/post/post.service.spec.js - About 35 mins to fix

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

          verify(connection) {
            expect(connection.request.url).toEqual(this.options.url, 'Request url missmatch.');
            expect(connection.request.method).toEqual(this.options.method, 'Request method missmatch.');
            if (this.options.hasOwnProperty('body')) {
              expect(connection.request.text()).toEqual(this.options.body, 'Request body missmatch.');
        Severity: Minor
        Found in client/app/helpers/fake-backend.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

        Function exports has a Cognitive Complexity of 6 (exceeds 5 allowed). Consider refactoring.
        Open

        module.exports = function(singleRun, callback) {
          return function() {
            let gulpStream = gulp.src(config.source);
        
            if (!singleRun) {
        Severity: Minor
        Found in tasks/client_copy.js - About 25 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

        Closing curly brace does not appear on the same line as the subsequent block.
        Open

          else {
        Severity: Minor
        Found in server/router.js by eslint

        Require Brace Style (brace-style)

        Brace style is closely related to indent style in programming and describes the placement of braces relative to their control statement and body. There are probably a dozen, if not more, brace styles in the world.

        The one true brace style is one of the most common brace styles in JavaScript, in which the opening brace of a block is placed on the same line as its corresponding statement or declaration. For example:

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

        One common variant of one true brace style is called Stroustrup, in which the else statements in an if-else construct, as well as catch and finally, must be on its own line after the preceding closing brace. For example:

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

        Another style is called Allman, in which all the braces are expected to be on their own lines without any extra indentation. For example:

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

        While no style is considered better than the other, most developers agree that having a consistent style throughout a project is important for its long-term maintainability.

        Rule Details

        This rule enforces consistent brace style for blocks.

        Options

        This rule has a string option:

        • "1tbs" (default) enforces one true brace style
        • "stroustrup" enforces Stroustrup style
        • "allman" enforces Allman style

        This rule has an object option for an exception:

        • "allowSingleLine": true (default false) allows the opening and closing braces for a block to be on the same line

        1tbs

        Examples of incorrect code for this rule with the default "1tbs" option:

        /*eslint brace-style: "error"*/
        
        function foo()
        {
          return true;
        }
        
        if (foo)
        {
          bar();
        }
        
        try
        {
          somethingRisky();
        } catch(e)
        {
          handleError();
        }
        
        if (foo) {
          bar();
        }
        else {
          baz();
        }

        Examples of correct code for this rule with the default "1tbs" option:

        /*eslint brace-style: "error"*/
        
        function foo() {
          return true;
        }
        
        if (foo) {
          bar();
        }
        
        if (foo) {
          bar();
        } else {
          baz();
        }
        
        try {
          somethingRisky();
        } catch(e) {
          handleError();
        }
        
        // when there are no braces, there are no problems
        if (foo) bar();
        else if (baz) boom();

        Examples of correct code for this rule with the "1tbs", { "allowSingleLine": true } options:

        /*eslint brace-style: ["error", "1tbs", { "allowSingleLine": true }]*/
        
        function nop() { return; }
        
        if (foo) { bar(); }
        
        if (foo) { bar(); } else { baz(); }
        
        try { somethingRisky(); } catch(e) { handleError(); }

        stroustrup

        Examples of incorrect code for this rule with the "stroustrup" option:

        /*eslint brace-style: ["error", "stroustrup"]*/
        
        function foo()
        {
          return true;
        }
        
        if (foo)
        {
          bar();
        }
        
        try
        {
          somethingRisky();
        } catch(e)
        {
          handleError();
        }
        
        if (foo) {
          bar();
        } else {
          baz();
        }

        Examples of correct code for this rule with the "stroustrup" option:

        /*eslint brace-style: ["error", "stroustrup"]*/
        
        function foo() {
          return true;
        }
        
        if (foo) {
          bar();
        }
        
        if (foo) {
          bar();
        }
        else {
          baz();
        }
        
        try {
          somethingRisky();
        }
        catch(e) {
          handleError();
        }
        
        // when there are no braces, there are no problems
        if (foo) bar();
        else if (baz) boom();

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

        /*eslint brace-style: ["error", "stroustrup", { "allowSingleLine": true }]*/
        
        function nop() { return; }
        
        if (foo) { bar(); }
        
        if (foo) { bar(); }
        else { baz(); }
        
        try { somethingRisky(); }
        catch(e) { handleError(); }

        allman

        Examples of incorrect code for this rule with the "allman" option:

        /*eslint brace-style: ["error", "allman"]*/
        
        function foo() {
          return true;
        }
        
        if (foo)
        {
          bar(); }
        
        try
        {
          somethingRisky();
        } catch(e)
        {
          handleError();
        }
        
        if (foo) {
          bar();
        } else {
          baz();
        }

        Examples of correct code for this rule with the "allman" option:

        /*eslint brace-style: ["error", "allman"]*/
        
        function foo()
        {
          return true;
        }
        
        if (foo)
        {
          bar();
        }
        
        if (foo)
        {
          bar();
        }
        else
        {
          baz();
        }
        
        try
        {
          somethingRisky();
        }
        catch(e)
        {
          handleError();
        }
        
        // when there are no braces, there are no problems
        if (foo) bar();
        else if (baz) boom();

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

        /*eslint brace-style: ["error", "allman", { "allowSingleLine": true }]*/
        
        function nop() { return; }
        
        if (foo) { bar(); }
        
        if (foo) { bar(); }
        else { baz(); }
        
        try { somethingRisky(); }
        catch(e) { handleError(); }

        When Not To Use It

        If your project will not be using the one true brace style, turn this rule off.

        Further Reading

        'module' is not defined.
        Open

        module.exports = function() {
        Severity: Minor
        Found in tasks/clean.js by eslint

        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.

        Further Reading

        'module' is not defined.
        Open

        module.exports = config;
        Severity: Minor
        Found in tasks/config/webpack.dist.js by eslint

        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.

        Further Reading

        Missing semicolon.
        Open

          }
        Severity: Minor
        Found in tasks/server_copy.js by eslint

        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:

        1. 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 ,.)
        2. The line is -- or ++ (in which case it will decrement/increment the next token.)
        3. It is a for(), while(), do, if(), or else, and there is no {
        4. 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.

        Further Reading

        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';
        Severity: Minor
        Found in tasks/server_start.js by eslint

        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/

        Unexpected function expression.
        Open

        gulp.task('test-dev', function(done) {
        Severity: Minor
        Found in gulpfile.js by eslint

        Suggest using arrow functions as callbacks. (prefer-arrow-callback)

        Arrow functions are suited to callbacks, because:

        • this keywords in arrow functions bind to the upper scope's.
        • The notation of the arrow function is shorter than function expression's.

        Rule Details

        This rule is aimed to flag usage of function expressions in an argument list.

        The following patterns are considered problems:

        /*eslint prefer-arrow-callback: "error"*/
        
        foo(function(a) { return a; });
        foo(function() { return this.a; }.bind(this));

        The following patterns are not considered problems:

        /*eslint prefer-arrow-callback: "error"*/
        /*eslint-env es6*/
        
        foo(a => a);
        foo(function*() { yield; });
        
        // this is not a callback.
        var foo = function foo(a) { return a; };
        
        // using `this` without `.bind(this)`.
        foo(function() { return this.a; });
        
        // recursively.
        foo(function bar(n) { return n && n + bar(n - 1); });

        Options

        This rule takes one optional argument, an object which is an options object.

        allowNamedFunctions

        This is a boolean option and it is false by default. When set to true, the rule doesn't warn on named functions used as callbacks.

        Examples of correct code for the { "allowNamedFunctions": true } option:

        /*eslint prefer-arrow-callback: ["error", { "allowNamedFunctions": true }]*/
        
        foo(function bar() {});

        allowUnboundThis

        This is a boolean option and it is true by default. When set to false, this option allows the use of this without restriction and checks for dynamically assigned this values such as when using Array.prototype.map with a context argument. Normally, the rule will flag the use of this whenever a function does not use bind() to specify the value of this constantly.

        Examples of incorrect code for the { "allowUnboundThis": false } option:

        /*eslint prefer-arrow-callback: ["error", { "allowUnboundThis": false }]*/
        /*eslint-env es6*/
        
        foo(function() { this.a; });
        
        foo(function() { (() => this); });
        
        someArray.map(function (itm) { return this.doSomething(itm); }, someObject);

        When Not To Use It

        This rule should not be used in ES3/5 environments.

        In ES2015 (ES6) or later, if you don't want to be notified about function expressions in an argument list, you can safely disable this rule. Source: http://eslint.org/docs/rules/

        Severity
        Category
        Status
        Source
        Language