INTO-CPS-Association/DTaaS

  console.log('Updating local-path to '+ env.LIBMS_LOCAL_PATH);

Close

---

title: prefer-template ruletype: suggestion relatedrules: - no-useless-concat

- quotes

In ES2015 (ES6), we can use template literals instead of string concatenation.

var str = "Hello, " + name + "!";

/*eslint-env es6*/

var str = `Hello, ${name}!`;

Rule Details

This rule is aimed to flag usage of + operators with strings.

Examples

Examples of incorrect code for this rule:

::: incorrect

/*eslint prefer-template: "error"*/

var str = "Hello, " + name + "!";
var str = "Time: " + (12 * 60 * 60 * 1000);

:::

Examples of correct code for this rule:

::: correct

/*eslint prefer-template: "error"*/
/*eslint-env es6*/

var str = "Hello World!";
var str = `Hello, ${name}!`;
var str = `Time: ${12 * 60 * 60 * 1000}`;

// This is reported by `no-useless-concat`.
var str = "Hello, " + "World!";

:::

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 string concatenation, you can safely disable this rule. Source: http://eslint.org/docs/rules/

const env = process.env;

Close

---

title: prefer-destructuring ruletype: suggestion furtherreading: - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment

- https://2ality.com/2015/01/es6-destructuring.html

With JavaScript ES6, a new syntax was added for creating variables from an array index or object property, called destructuring. This rule enforces usage of destructuring instead of accessing a property through a member expression.

Rule Details

Options

This rule takes two sets of configuration objects. The first object parameter determines what types of destructuring the rule applies to.

The two properties, array and object, can be used to turn on or off the destructuring requirement for each of those types independently. By default, both are true.

Alternatively, you can use separate configurations for different assignment types. It accepts 2 other keys instead of array and object.

One key is VariableDeclarator and the other is AssignmentExpression, which can be used to control the destructuring requirement for each of those types independently. Each property accepts an object that accepts two properties, array and object, which can be used to control the destructuring requirement for each of array and object independently for variable declarations and assignment expressions. By default, array and object are set to true for both VariableDeclarator and AssignmentExpression.

The rule has a second object with a single key, enforceForRenamedProperties, which determines whether the object destructuring applies to renamed variables.

Note: It is not possible to determine if a variable will be referring to an object or an array at runtime. This rule therefore guesses the assignment type by checking whether the key being accessed is an integer. This can lead to the following possibly confusing situations:

• Accessing an object property whose key is an integer will fall under the category array destructuring.
• Accessing an array element through a computed index will fall under the category object destructuring.

The --fix option on the command line fixes only problems reported in variable declarations, and among them only those that fall under the category object destructuring. Furthermore, the name of the declared variable has to be the same as the name used for non-computed member access in the initializer. For example, var foo = object.foo can be automatically fixed by this rule. Problems that involve computed member access (e.g., var foo = object[foo]) or renamed properties (e.g., var foo = object.bar) are not automatically fixed.

Examples of incorrect code for this rule:

::: incorrect

// With `array` enabled
var foo = array[0];
bar.baz = array[0];

// With `object` enabled
var foo = object.foo;
var foo = object['foo'];

:::

Examples of correct code for this rule:

::: correct

// With `array` enabled
var [ foo ] = array;
var foo = array[someIndex];
[bar.baz] = array;


// With `object` enabled
var { foo } = object;

var foo = object.bar;

let foo;
({ foo } = object);

:::

Examples of incorrect code when enforceForRenamedProperties is enabled:

::: incorrect

var foo = object.bar;

:::

Examples of correct code when enforceForRenamedProperties is enabled:

::: correct

var { bar: foo } = object;

:::

Examples of additional correct code when enforceForRenamedProperties is enabled:

::: correct

class C {
    #x;
    foo() {
        const bar = this.#x; // private identifiers are not allowed in destructuring
    }
}

:::

An example configuration, with the defaults array and object filled in, looks like this:

{
  "rules": {
    "prefer-destructuring": ["error", {
      "array": true,
      "object": true
    }, {
      "enforceForRenamedProperties": false
    }]
  }
}

The two properties, array and object, which can be used to turn on or off the destructuring requirement for each of those types independently. By default, both are true.

For example, the following configuration enforces only object destructuring, but not array destructuring:

{
  "rules": {
    "prefer-destructuring": ["error", {"object": true, "array": false}]
  }
}

An example configuration, with the defaults VariableDeclarator and AssignmentExpression filled in, looks like this:

{
  "rules": {
    "prefer-destructuring": ["error", {
      "VariableDeclarator": {
        "array": false,
        "object": true
      },
      "AssignmentExpression": {
        "array": true,
        "object": true
      }
    }, {
      "enforceForRenamedProperties": false
    }]
  }
}

The two properties, VariableDeclarator and AssignmentExpression, which can be used to turn on or off the destructuring requirement for array and object. By default, all values are true.

For example, the following configuration enforces object destructuring in variable declarations and enforces array destructuring in assignment expressions.

{
  "rules": {
    "prefer-destructuring": ["error", {
      "VariableDeclarator": {
        "array": false,
        "object": true
      },
      "AssignmentExpression": {
        "array": true,
        "object": false
      }
    }, {
      "enforceForRenamedProperties": false
    }]
  }
}

Examples of correct code when object destructuring in VariableDeclarator is enforced:

::: correct

/* eslint prefer-destructuring: ["error", {VariableDeclarator: {object: true}}] */
var {bar: foo} = object;

:::

Examples of correct code when array destructuring in AssignmentExpression is enforced:

::: correct

/* eslint prefer-destructuring: ["error", {AssignmentExpression: {array: true}}] */
[bar] = array;

:::

When Not To Use It

If you want to be able to access array indices or object properties directly, you can either configure the rule to your tastes or disable the rule entirely.

Additionally, if you intend to access large array indices directly, like:

var foo = array[100];

Then the array part of this rule is not recommended, as destructuring does not match this use case very well.

Or for non-iterable 'array-like' objects:

var $ = require('jquery');
var foo = $('body')[0];
var [bar] = $('body'); // fails with a TypeError

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

  config['port'] = env.LIBMS_PORT;

Close

---

title: dot-notation

rule_type: suggestion

In JavaScript, one can access properties using the dot notation (foo.bar) or square-bracket notation (foo["bar"]). However, the dot notation is often preferred because it is easier to read, less verbose, and works better with aggressive JavaScript minimizers.

foo["bar"];

Rule Details

This rule is aimed at maintaining code consistency and improving code readability by encouraging use of the dot notation style whenever possible. As such, it will warn when it encounters an unnecessary use of square-bracket notation.

Examples of incorrect code for this rule:

:::incorrect

/*eslint dot-notation: "error"*/

var x = foo["bar"];

:::

Examples of correct code for this rule:

:::correct

/*eslint dot-notation: "error"*/

var x = foo.bar;

var x = foo[bar];    // Property name is a variable, square-bracket notation required

:::

Options

This rule accepts a single options argument:

• Set the allowKeywords option to false (default is true) to follow ECMAScript version 3 compatible style, avoiding dot notation for reserved word properties.
• Set the allowPattern option to a regular expression string to allow bracket notation for property names that match a pattern (by default, no pattern is tested).

allowKeywords

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

:::correct

/*eslint dot-notation: ["error", { "allowKeywords": false }]*/

var foo = { "class": "CS 101" }
var x = foo["class"]; // Property name is a reserved word, square-bracket notation required

:::

Examples of additional correct code for the { "allowKeywords": false } option:

:::correct

/*eslint dot-notation: ["error", { "allowKeywords": false }]*/

class C {
    #in;
    foo() {
        this.#in; // Dot notation is required for private identifiers
    }
}

:::

allowPattern

For example, when preparing data to be sent to an external API, it is often required to use property names that include underscores. If the camelcase rule is in effect, these snake case properties would not be allowed. By providing an allowPattern to the dot-notation rule, these snake case properties can be accessed with bracket notation.

Examples of correct code for the sample { "allowPattern": "^[a-z]+(_[a-z]+)+$" } option:

:::correct

/*eslint camelcase: "error"*/
/*eslint dot-notation: ["error", { "allowPattern": "^[a-z]+(_[a-z]+)+$" }]*/

var data = {};
data.foo_bar = 42;

var data = {};
data["fooBar"] = 42;

var data = {};
data["foo_bar"] = 42; // no warning

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

console.log( yamlFilePath + ' updated successfully.');

Close

---

title: prefer-template ruletype: suggestion relatedrules: - no-useless-concat

- quotes

In ES2015 (ES6), we can use template literals instead of string concatenation.

var str = "Hello, " + name + "!";

/*eslint-env es6*/

var str = `Hello, ${name}!`;

Rule Details

This rule is aimed to flag usage of + operators with strings.

Examples

Examples of incorrect code for this rule:

::: incorrect

/*eslint prefer-template: "error"*/

var str = "Hello, " + name + "!";
var str = "Time: " + (12 * 60 * 60 * 1000);

:::

Examples of correct code for this rule:

::: correct

/*eslint prefer-template: "error"*/
/*eslint-env es6*/

var str = "Hello World!";
var str = `Hello, ${name}!`;
var str = `Time: ${12 * 60 * 60 * 1000}`;

// This is reported by `no-useless-concat`.
var str = "Hello, " + "World!";

:::

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 string concatenation, you can safely disable this rule. Source: http://eslint.org/docs/rules/

  console.log('Updating PORT to '+ env.LIBMS_PORT);

Close

---

title: prefer-template ruletype: suggestion relatedrules: - no-useless-concat

- quotes

In ES2015 (ES6), we can use template literals instead of string concatenation.

var str = "Hello, " + name + "!";

/*eslint-env es6*/

var str = `Hello, ${name}!`;

Rule Details

This rule is aimed to flag usage of + operators with strings.

Examples

Examples of incorrect code for this rule:

::: incorrect

/*eslint prefer-template: "error"*/

var str = "Hello, " + name + "!";
var str = "Time: " + (12 * 60 * 60 * 1000);

:::

Examples of correct code for this rule:

::: correct

/*eslint prefer-template: "error"*/
/*eslint-env es6*/

var str = "Hello World!";
var str = `Hello, ${name}!`;
var str = `Time: ${12 * 60 * 60 * 1000}`;

// This is reported by `no-useless-concat`.
var str = "Hello, " + "World!";

:::

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 string concatenation, you can safely disable this rule. Source: http://eslint.org/docs/rules/

  console.log('Updating PORT to '+ env.LIBMS_PORT);

Close

---

title: no-console ruletype: suggestion relatedrules: - no-alert

- no-debugger

In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production.

console.log("Made it here.");
console.error("That shouldn't have happened.");

Rule Details

This rule disallows calls or assignments to methods of the console object.

Examples of incorrect code for this rule:

::: incorrect

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

console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
console.log = foo();

:::

Examples of correct code for this rule:

::: correct

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

// custom console
Console.log("Hello world!");

:::

Options

This rule has an object option for exceptions:

• "allow" has an array of strings which are allowed methods of the console object

Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] } option:

::: correct

/* eslint no-console: ["error", { allow: ["warn", "error"] }] */

console.warn("Log a warn level message.");
console.error("Log an error level message.");

:::

When Not To Use It

If you're using Node.js, however, console is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.

Another case where you might not use this rule is if you want to enforce console calls and not console overwrites. For example:

/* eslint no-console: ["error", { allow: ["warn"] }] */
console.error = function (message) {
  throw new Error(message);
};

With the no-console rule in the above example, ESLint will report an error. For the above example, you can disable the rule:

// eslint-disable-next-line no-console
console.error = function (message) {
  throw new Error(message);
};

// or

console.error = function (message) {  // eslint-disable-line no-console
  throw new Error(message);
};

However, you might not want to manually add eslint-disable-next-line or eslint-disable-line. You can achieve the effect of only receiving errors for console calls with the no-restricted-syntax rule:

{
    "rules": {
        "no-console": "off",
        "no-restricted-syntax": [
            "error",
            {
                "selector": "CallExpression[callee.object.name='console'][callee.property.name!=/^(log|warn|error|info|trace)$/]",
                "message": "Unexpected property on console object was called"
            }
        ]
    }
}

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

  console.log('Updating local-path to '+ env.LIBMS_LOCAL_PATH);

Close

---

title: no-console ruletype: suggestion relatedrules: - no-alert

- no-debugger

In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production.

console.log("Made it here.");
console.error("That shouldn't have happened.");

Rule Details

This rule disallows calls or assignments to methods of the console object.

Examples of incorrect code for this rule:

::: incorrect

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

console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
console.log = foo();

:::

Examples of correct code for this rule:

::: correct

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

// custom console
Console.log("Hello world!");

:::

Options

This rule has an object option for exceptions:

• "allow" has an array of strings which are allowed methods of the console object

Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] } option:

::: correct

/* eslint no-console: ["error", { allow: ["warn", "error"] }] */

console.warn("Log a warn level message.");
console.error("Log an error level message.");

:::

When Not To Use It

If you're using Node.js, however, console is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.

Another case where you might not use this rule is if you want to enforce console calls and not console overwrites. For example:

/* eslint no-console: ["error", { allow: ["warn"] }] */
console.error = function (message) {
  throw new Error(message);
};

With the no-console rule in the above example, ESLint will report an error. For the above example, you can disable the rule:

// eslint-disable-next-line no-console
console.error = function (message) {
  throw new Error(message);
};

// or

console.error = function (message) {  // eslint-disable-line no-console
  throw new Error(message);
};

However, you might not want to manually add eslint-disable-next-line or eslint-disable-line. You can achieve the effect of only receiving errors for console calls with the no-restricted-syntax rule:

{
    "rules": {
        "no-console": "off",
        "no-restricted-syntax": [
            "error",
            {
                "selector": "CallExpression[callee.object.name='console'][callee.property.name!=/^(log|warn|error|info|trace)$/]",
                "message": "Unexpected property on console object was called"
            }
        ]
    }
}

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

console.log( yamlFilePath + ' updated successfully.');

Close

---

title: no-console ruletype: suggestion relatedrules: - no-alert

- no-debugger

In JavaScript that is designed to be executed in the browser, it's considered a best practice to avoid using methods on console. Such messages are considered to be for debugging purposes and therefore not suitable to ship to the client. In general, calls using console should be stripped before being pushed to production.

console.log("Made it here.");
console.error("That shouldn't have happened.");

Rule Details

This rule disallows calls or assignments to methods of the console object.

Examples of incorrect code for this rule:

::: incorrect

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

console.log("Log a debug level message.");
console.warn("Log a warn level message.");
console.error("Log an error level message.");
console.log = foo();

:::

Examples of correct code for this rule:

::: correct

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

// custom console
Console.log("Hello world!");

:::

Options

This rule has an object option for exceptions:

• "allow" has an array of strings which are allowed methods of the console object

Examples of additional correct code for this rule with a sample { "allow": ["warn", "error"] } option:

::: correct

/* eslint no-console: ["error", { allow: ["warn", "error"] }] */

console.warn("Log a warn level message.");
console.error("Log an error level message.");

:::

When Not To Use It

If you're using Node.js, however, console is used to output information to the user and so is not strictly used for debugging purposes. If you are developing for Node.js then you most likely do not want this rule enabled.

Another case where you might not use this rule is if you want to enforce console calls and not console overwrites. For example:

/* eslint no-console: ["error", { allow: ["warn"] }] */
console.error = function (message) {
  throw new Error(message);
};

With the no-console rule in the above example, ESLint will report an error. For the above example, you can disable the rule:

// eslint-disable-next-line no-console
console.error = function (message) {
  throw new Error(message);
};

// or

console.error = function (message) {  // eslint-disable-line no-console
  throw new Error(message);
};

However, you might not want to manually add eslint-disable-next-line or eslint-disable-line. You can achieve the effect of only receiving errors for console calls with the no-restricted-syntax rule:

{
    "rules": {
        "no-console": "off",
        "no-restricted-syntax": [
            "error",
            {
                "selector": "CallExpression[callee.object.name='console'][callee.property.name!=/^(log|warn|error|info|trace)$/]",
                "message": "Unexpected property on console object was called"
            }
        ]
    }
}

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