huridocs/uwazi

title: no-param-reassign ruletype: suggestion furtherreading:

- https://spin.atomicobject.com/2011/04/10/javascript-don-t-reassign-your-function-arguments/

Assignment to variables declared as function parameters can be misleading and lead to confusing behavior, as modifying function parameters will also mutate the arguments object when not in strict mode (see When Not To Use It below). Often, assignment to function parameters is unintended and indicative of a mistake or programmer error.

This rule can be also configured to fail when function parameters are modified. Side effects on parameters can cause counter-intuitive execution flow and make errors difficult to track down.

Rule Details

This rule aims to prevent unintended behavior caused by modification or reassignment of function parameters.

Examples of incorrect code for this rule:

::: incorrect

/*eslint no-param-reassign: "error"*/

function foo(bar) {
    bar = 13;
}

function foo(bar) {
    bar++;
}

function foo(bar) {
    for (bar in baz) {}
}

function foo(bar) {
    for (bar of baz) {}
}

:::

Examples of correct code for this rule:

::: correct

/*eslint no-param-reassign: "error"*/

function foo(bar) {
    var baz = bar;
}

:::

Options

This rule takes one option, an object, with a boolean property "props", and arrays "ignorePropertyModificationsFor" and "ignorePropertyModificationsForRegex". "props" is false by default. If "props" is set to true, this rule warns against the modification of parameter properties unless they're included in "ignorePropertyModificationsFor" or "ignorePropertyModificationsForRegex", which is an empty array by default.

props

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

::: correct

/*eslint no-param-reassign: ["error", { "props": false }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

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

::: incorrect

/*eslint no-param-reassign: ["error", { "props": true }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsFor" set:

::: correct

/*eslint no-param-reassign: ["error", { "props": true, "ignorePropertyModificationsFor": ["bar"] }]*/

function foo(bar) {
    bar.prop = "value";
}

function foo(bar) {
    delete bar.aaa;
}

function foo(bar) {
    bar.aaa++;
}

function foo(bar) {
    for (bar.aaa in baz) {}
}

function foo(bar) {
    for (bar.aaa of baz) {}
}

:::

Examples of correct code for the { "props": true } option with "ignorePropertyModificationsForRegex" set:

::: correct

/*eslint no-param-reassign: ["error", { "props": true, "ignorePropertyModificationsForRegex": ["^bar"] }]*/

function foo(barVar) {
    barVar.prop = "value";
}

function foo(barrito) {
    delete barrito.aaa;
}

function foo(bar_) {
    bar_.aaa++;
}

function foo(barBaz) {
    for (barBaz.aaa in baz) {}
}

function foo(barBaz) {
    for (barBaz.aaa of baz) {}
}

:::

When Not To Use It

If you want to allow assignment to function parameters, then you can safely disable this rule.

Strict mode code doesn't sync indices of the arguments object with each parameter binding. Therefore, this rule is not necessary to protect against arguments object mutation in ESM modules or other strict mode functions. Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

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/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

title: func-names ruletype: suggestion furtherreading: - https://web.archive.org/web/20201112040809/http://markdaggett.com/blog/2013/02/15/functions-explained/

- https://2ality.com/2015/09/function-names-es6.html

A pattern that's becoming more common is to give function expressions names to aid in debugging. For example:

Foo.prototype.bar = function bar() {};

Adding the second bar in the above example is optional. If you leave off the function name then when the function throws an exception you are likely to get something similar to anonymous function in the stack trace. If you provide the optional name for a function expression then you will get the name of the function expression in the stack trace.

Rule Details

This rule can enforce or disallow the use of named function expressions.

Options

This rule has a string option:

• "always" (default) requires function expressions to have a name
• "as-needed" requires function expressions to have a name, if the name isn't assigned automatically per the ECMAScript specification.
• "never" disallows named function expressions, except in recursive functions, where a name is needed

This rule has an object option:

• "generators": "always" | "as-needed" | "never"
  • "always" require named generators
  • "as-needed" require named generators if the name isn't assigned automatically per the ECMAScript specification.
  • "never" disallow named generators where possible.

When a value for generators is not provided the behavior for generator functions falls back to the base option.

Please note that "always" and "as-needed" require function expressions and function declarations in export default declarations to have a name.

always

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

::: incorrect

/*eslint func-names: ["error", "always"]*/

Foo.prototype.bar = function() {};

const cat = {
  meow: function() {}
}

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

export default function() {}

:::

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

::: correct

/*eslint func-names: ["error", "always"]*/

Foo.prototype.bar = function bar() {};

const cat = {
  meow() {}
}

(function bar() {
    // ...
}())

export default function foo() {}

:::

as-needed

ECMAScript 6 introduced a name property on all functions. The value of name is determined by evaluating the code around the function to see if a name can be inferred. For example, a function assigned to a variable will automatically have a name property equal to the name of the variable. The value of name is then used in stack traces for easier debugging.

Examples of incorrect code for this rule with the "as-needed" option:

::: incorrect

/*eslint func-names: ["error", "as-needed"]*/

Foo.prototype.bar = function() {};

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

export default function() {}

:::

Examples of correct code for this rule with the "as-needed" option:

::: correct

/*eslint func-names: ["error", "as-needed"]*/

var bar = function() {};

const cat = {
  meow: function() {}
}

class C {
    #bar = function() {};
    baz = function() {};
}

quux ??= function() {};

(function bar() {
    // ...
}())

export default function foo() {}

:::

never

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

::: incorrect

/*eslint func-names: ["error", "never"]*/

Foo.prototype.bar = function bar() {};

(function bar() {
    // ...
}())

:::

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

::: correct

/*eslint func-names: ["error", "never"]*/

Foo.prototype.bar = function() {};

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

:::

generators

Examples of incorrect code for this rule with the "always", { "generators": "as-needed" } options:

::: incorrect

/*eslint func-names: ["error", "always", { "generators": "as-needed" }]*/

(function*() {
    // ...
}())

:::

Examples of correct code for this rule with the "always", { "generators": "as-needed" } options:

::: correct

/*eslint func-names: ["error", "always", { "generators": "as-needed" }]*/

var foo = function*() {};

:::

Examples of incorrect code for this rule with the "always", { "generators": "never" } options:

::: incorrect

/*eslint func-names: ["error", "always", { "generators": "never" }]*/

var foo = bar(function *baz() {});

:::

Examples of correct code for this rule with the "always", { "generators": "never" } options:

::: correct

/*eslint func-names: ["error", "always", { "generators": "never" }]*/

var foo = bar(function *() {});

:::

Examples of incorrect code for this rule with the "as-needed", { "generators": "never" } options:

::: incorrect

/*eslint func-names: ["error", "as-needed", { "generators": "never" }]*/

var foo = bar(function *baz() {});

:::

Examples of correct code for this rule with the "as-needed", { "generators": "never" } options:

::: correct

/*eslint func-names: ["error", "as-needed", { "generators": "never" }]*/

var foo = bar(function *() {});

:::

Examples of incorrect code for this rule with the "never", { "generators": "always" } options:

::: incorrect

/*eslint func-names: ["error", "never", { "generators": "always" }]*/

var foo = bar(function *() {});

:::

Examples of correct code for this rule with the "never", { "generators": "always" } options:

::: correct

/*eslint func-names: ["error", "never", { "generators": "always" }]*/

var foo = bar(function *baz() {});

:::

Compatibility

• JSCS: requireAnonymousFunctions
• JSCS: disallowAnonymousFunctions Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/

For more information visit Source: http://eslint.org/docs/rules/