rike422/loose-leaf

View on GitHub
client/webpack.config.js

Summary

Maintainability
A
0 mins
Test Coverage

It's not necessary to initialize 'config' to undefined.
Open

let config = undefined
Severity: Minor
Found in client/webpack.config.js by eslint

Disallow Initializing to undefined (no-undef-init)

In JavaScript, a variable that is declared and not initialized to any value automatically gets the value of undefined. For example:

var foo;

console.log(foo === undefined);     // true

It's therefore unnecessary to initialize a variable to undefined, such as:

var foo = undefined;

It's considered a best practice to avoid initializing variables to undefined.

Rule Details

This rule aims to eliminate variable declarations that initialize to undefined.

Examples of incorrect code for this rule:

/*eslint no-undef-init: "error"*/
/*eslint-env es6*/

var foo = undefined;
let bar = undefined;

Examples of correct code for this rule:

/*eslint no-undef-init: "error"*/
/*eslint-env es6*/

var foo;
let bar;
const baz = undefined;

When Not To Use It

There is one situation where initializing to undefined behaves differently than omitting the initialization, and that's when a var declaration occurs inside of a loop. For example:

Example of incorrect code for this rule:

for (i = 0; i < 10; i++) {
    var x = undefined;
    console.log(x);
    x = i;
}

In this case, the var x is hoisted out of the loop, effectively creating:

var x;

for (i = 0; i < 10; i++) {
    x = undefined;
    console.log(x);
    x = i;
}

If you were to remove the initialization, then the behavior of the loop changes:

for (i = 0; i < 10; i++) {
    var x;
    console.log(x);
    x = i;
}

This code is equivalent to:

var x;

for (i = 0; i < 10; i++) {
    console.log(x);
    x = i;
}

This produces a different outcome than defining var x = undefined in the loop, as x is no longer reset to undefined each time through the loop.

If you're using such an initialization inside of a loop, then you should disable this rule.

Example of correct code for this rule, because it is disabled on a specific line:

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

for (i = 0; i < 10; i++) {
    var x = undefined; // eslint-disable-line no-undef-init
    console.log(x);
    x = i;
}

Related Rules

Expected '===' and instead saw '=='.
Open

if (NODE_ENV == 'prod') {
Severity: Minor
Found in client/webpack.config.js by eslint

Require === and !== (eqeqeq)

It is considered good practice to use the type-safe equality operators === and !== instead of their regular counterparts == and !=.

The reason for this is that == and != do type coercion which follows the rather obscure Abstract Equality Comparison Algorithm. For instance, the following statements are all considered true:

  • [] == false
  • [] == ![]
  • 3 == "03"

If one of those occurs in an innocent-looking statement such as a == b the actual problem is very difficult to spot.

Rule Details

This rule is aimed at eliminating the type-unsafe equality operators.

Examples of incorrect code for this rule:

/*eslint eqeqeq: "error"*/

if (x == 42) { }

if ("" == text) { }

if (obj.getStuff() != undefined) { }

The --fix option on the command line automatically fixes some problems reported by this rule. A problem is only fixed if one of the operands is a typeof expression, or if both operands are literals with the same type.

Options

always

The "always" option (default) enforces the use of === and !== in every situation (except when you opt-in to more specific handling of null [see below]).

Examples of incorrect code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a == b
foo == true
bananas != 1
value == undefined
typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

Examples of correct code for the "always" option:

/*eslint eqeqeq: ["error", "always"]*/

a === b
foo === true
bananas !== 1
value === undefined
typeof foo === 'undefined'
'hello' !== 'world'
0 === 0
true === true
foo === null

This rule optionally takes a second argument, which should be an object with the following supported properties:

  • "null": Customize how this rule treats null literals. Possible values:
    • always (default) - Always use === or !==.
    • never - Never use === or !== with null.
    • ignore - Do not apply this rule to null.

smart

The "smart" option enforces the use of === and !== except for these cases:

  • Comparing two literal values
  • Evaluating the value of typeof
  • Comparing against null

Examples of incorrect code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

// comparing two variables requires ===
a == b

// only one side is a literal
foo == true
bananas != 1

// comparing to undefined requires ===
value == undefined

Examples of correct code for the "smart" option:

/*eslint eqeqeq: ["error", "smart"]*/

typeof foo == 'undefined'
'hello' != 'world'
0 == 0
true == true
foo == null

allow-null

Deprecated: Instead of using this option use "always" and pass a "null" option property with value "ignore". This will tell eslint to always enforce strict equality except when comparing with the null literal.

["error", "always", {"null": "ignore"}]

When Not To Use It

If you don't want to enforce a style for using equality operators, then it's safe to disable this rule. Source: http://eslint.org/docs/rules/

Read-only global 'process' should not be modified.
Open

process = require('process')
Severity: Minor
Found in client/webpack.config.js by eslint

Disallow assignment to native objects or read-only global variables (no-global-assign)

JavaScript environments contain a number of built-in global variables, such as window in browsers and process in Node.js. In almost all cases, you don't want to assign a value to these global variables as doing so could result in losing access to important functionality. For example, you probably don't want to do this in browser code:

window = {};

While examples such as window are obvious, there are often hundreds of built-in global objects provided by JavaScript environments. It can be hard to know if you're assigning to a global variable or not.

Rule Details

This rule disallows modifications to read-only global variables.

ESLint has the capability to configure global variables as read-only.

  • [Specifying Environments](../user-guide/configuring#specifying-environments)
  • [Specifying Globals](../user-guide/configuring#specifying-globals)

Examples of incorrect code for this rule:

/*eslint no-global-assign: "error"*/

Object = null
undefined = 1
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/

window = {}
length = 1
top = 1
/*eslint no-global-assign: "error"*/
/*globals a:false*/

a = 1

Examples of correct code for this rule:

/*eslint no-global-assign: "error"*/

a = 1
var b = 1
b = 2
/*eslint no-global-assign: "error"*/
/*eslint-env browser*/

onload = function() {}
/*eslint no-global-assign: "error"*/
/*globals a:true*/

a = 1

Options

This rule accepts an exceptions option, which can be used to specify a list of builtins for which reassignments will be allowed:

{
    "rules": {
        "no-global-assign": ["error", {"exceptions": ["Object"]}]
    }
}

When Not To Use It

If you are trying to override one of the native objects.

Related Rules

There are no issues that match your filters.

Category
Status