| GitLab Variable Name | Variable Name in .env of docker compose file | Default Value |

Close

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

} catch (e) {

Close

---

title: no-empty ruletype: suggestion relatedrules:

- no-empty-function

Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

Rule Details

This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

Examples of incorrect code for this rule:

::: incorrect

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

if (foo) {
}

while (foo) {
}

switch(foo) {
}

try {
    doSomething();
} catch(ex) {

} finally {

}

:::

Examples of correct code for this rule:

::: correct

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

if (foo) {
    // empty
}

while (foo) {
    /* empty */
}

try {
    doSomething();
} catch (ex) {
    // continue regardless of error
}

try {
    doSomething();
} finally {
    /* continue regardless of error */
}

:::

Options

This rule has an object option for exceptions:

• "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

allowEmptyCatch

Examples of additional correct code for this rule with the { "allowEmptyCatch": true } option:

::: correct

/* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
try {
    doSomething();
} catch (ex) {}

try {
    doSomething();
}
catch (ex) {}
finally {
    /* continue regardless of error */
}

:::

When Not To Use It

If you intentionally use empty block statements then you can disable this rule. Source: http://eslint.org/docs/rules/

let args = [rabbitmqConfig.username, rabbitmqConfig.password];

Close

---

title: prefer-const ruletype: suggestion relatedrules: - no-var

- no-use-before-define

If a variable is never reassigned, using the const declaration is better.

const declaration tells readers, "this variable is never reassigned," reducing cognitive load and improving maintainability.

Rule Details

This rule is aimed at flagging variables that are declared using let keyword, but never reassigned after the initial assignment.

Examples of incorrect code for this rule:

::: incorrect

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

// it's initialized and never reassigned.
let a = 3;
console.log(a);

let a;
a = 0;
console.log(a);

class C {
    static {
        let a;
        a = 0;
        console.log(a);
    }
}

// `i` is redefined (not reassigned) on each loop step.
for (let i in [1, 2, 3]) {
    console.log(i);
}

// `a` is redefined (not reassigned) on each loop step.
for (let a of [1, 2, 3]) {
    console.log(a);
}

:::

Examples of correct code for this rule:

::: correct

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

// using const.
const a = 0;

// it's never initialized.
let a;
console.log(a);

// it's reassigned after initialized.
let a;
a = 0;
a = 1;
console.log(a);

// it's initialized in a different block from the declaration.
let a;
if (true) {
    a = 0;
}
console.log(a);

// it's initialized in a different scope.
let a;
class C {
    #x;
    static {
        a = obj => obj.#x;
    }
}

// it's initialized at a place that we cannot write a variable declaration.
let a;
if (true) a = 0;
console.log(a);

// `i` gets a new binding each iteration
for (const i in [1, 2, 3]) {
  console.log(i);
}

// `a` gets a new binding each iteration
for (const a of [1, 2, 3]) {
  console.log(a);
}

// `end` is never reassigned, but we cannot separate the declarations without modifying the scope.
for (let i = 0, end = 10; i < end; ++i) {
    console.log(i);
}

// `predicate` is only assigned once but cannot be separately declared as `const`
let predicate;
[object.type, predicate] = foo();

// `a` is only assigned once but cannot be separately declared as `const`
let a;
const b = {};
({ a, c: b.c } = func());

// suggest to use `no-var` rule.
var b = 3;
console.log(b);

:::

Options

{
    "prefer-const": ["error", {
        "destructuring": "any",
        "ignoreReadBeforeAssign": false
    }]
}

destructuring

The kind of the way to address variables in destructuring. There are 2 values:

• "any" (default) - If any variables in destructuring should be const, this rule warns for those variables.
• "all" - If all variables in destructuring should be const, this rule warns the variables. Otherwise, ignores them.

Examples of incorrect code for the default {"destructuring": "any"} option:

::: incorrect

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

let {a, b} = obj;    /*error 'b' is never reassigned, use 'const' instead.*/
a = a + 1;

:::

Examples of correct code for the default {"destructuring": "any"} option:

::: correct

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

// using const.
const {a: a0, b} = obj;
const a = a0 + 1;

// all variables are reassigned.
let {a, b} = obj;
a = a + 1;
b = b + 1;

:::

Examples of incorrect code for the {"destructuring": "all"} option:

::: incorrect

/*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// all of `a` and `b` should be const, so those are warned.
let {a, b} = obj;    /*error 'a' is never reassigned, use 'const' instead.
                             'b' is never reassigned, use 'const' instead.*/

:::

Examples of correct code for the {"destructuring": "all"} option:

::: correct

/*eslint prefer-const: ["error", {"destructuring": "all"}]*/
/*eslint-env es6*/

// 'b' is never reassigned, but all of `a` and `b` should not be const, so those are ignored.
let {a, b} = obj;
a = a + 1;

:::

ignoreReadBeforeAssign

This is an option to avoid conflicting with no-use-before-define rule (without "nofunc" option). If true is specified, this rule will ignore variables that are read between the declaration and the first assignment. Default is false.

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

::: correct

/*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": true}]*/
/*eslint-env es6*/

let timer;
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}
timer = setInterval(initialize, 100);

:::

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

::: correct

/*eslint prefer-const: ["error", {"ignoreReadBeforeAssign": false}]*/
/*eslint-env es6*/

const timer = setInterval(initialize, 100);
function initialize() {
    if (foo()) {
        clearInterval(timer);
    }
}

:::

When Not To Use It

If you don't want to be notified about variables that are never reassigned after initial assignment, you can safely disable this rule. Source: http://eslint.org/docs/rules/

} catch (e) {}

Close

---

title: no-empty ruletype: suggestion relatedrules:

- no-empty-function

Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

Rule Details

This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

Examples of incorrect code for this rule:

::: incorrect

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

if (foo) {
}

while (foo) {
}

switch(foo) {
}

try {
    doSomething();
} catch(ex) {

} finally {

}

:::

Examples of correct code for this rule:

::: correct

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

if (foo) {
    // empty
}

while (foo) {
    /* empty */
}

try {
    doSomething();
} catch (ex) {
    // continue regardless of error
}

try {
    doSomething();
} finally {
    /* continue regardless of error */
}

:::

Options

This rule has an object option for exceptions:

• "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

allowEmptyCatch

Examples of additional correct code for this rule with the { "allowEmptyCatch": true } option:

::: correct

/* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
try {
    doSomething();
} catch (ex) {}

try {
    doSomething();
}
catch (ex) {}
finally {
    /* continue regardless of error */
}

:::

When Not To Use It

If you intentionally use empty block statements then you can disable this rule. Source: http://eslint.org/docs/rules/

//log(chalk.redBright("Remember to change the default password for admin\n"));

Close

---

title: spaced-comment ruletype: suggestion relatedrules:

- spaced-line-comment

Some style guides require or disallow a whitespace immediately after the initial // or /* of a comment. Whitespace after the // or /* makes it easier to read text in comments. On the other hand, commenting out code is easier without having to put a whitespace right after the // or /*.

Rule Details

This rule will enforce consistency of spacing after the start of a comment // or /*. It also provides several exceptions for various documentation styles.

Options

The rule takes two options.

• The first is a string which be either "always" or "never". The default is "always".

  • If "always" then the // or /* must be followed by at least one whitespace.
  • If "never" then there should be no whitespace following.

• This rule can also take a 2nd option, an object with any of the following keys: "exceptions" and "markers".

  • The "exceptions" value is an array of string patterns which are considered exceptions to the rule. The rule will not warn when the pattern starts from the beginning of the comment and repeats until the end of the line or */ if the comment is a single line comment. Please note that exceptions are ignored if the first argument is "never".

  "spaced-comment": ["error", "always", { "exceptions": ["-", "+"] }]

  • The "markers" value is an array of string patterns which are considered markers for docblock-style comments, such as an additional /, used to denote documentation read by doxygen, vsdoc, etc. which must have additional characters. The "markers" array will apply regardless of the value of the first argument, e.g. "always" or "never".

  "spaced-comment": ["error", "always", { "markers": ["/"] }]

The difference between a marker and an exception is that a marker only appears at the beginning of the comment whereas exceptions can occur anywhere in the comment string.

You can also define separate exceptions and markers for block and line comments. The "block" object can have an additional key "balanced", a boolean that specifies if inline block comments should have balanced spacing. The default value is false.

• If "balanced": true and "always" then the /* must be followed by at least one whitespace, and the */ must be preceded by at least one whitespace.

• If "balanced": true and "never" then there should be no whitespace following /* or preceding */.

• If "balanced": false then balanced whitespace is not enforced.

"spaced-comment": ["error", "always", {
    "line": {
        "markers": ["/"],
        "exceptions": ["-", "+"]
    },
    "block": {
        "markers": ["!"],
        "exceptions": ["*"],
        "balanced": true
    }
}]

always

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

::: incorrect

/*eslint spaced-comment: ["error", "always"]*/

//This is a comment with no whitespace at the beginning

/*This is a comment with no whitespace at the beginning */

:::

::: incorrect

/* eslint spaced-comment: ["error", "always", { "block": { "balanced": true } }] */
/* This is a comment with whitespace at the beginning but not the end*/

:::

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

::: correct

/* eslint spaced-comment: ["error", "always"] */

// This is a comment with a whitespace at the beginning

/* This is a comment with a whitespace at the beginning */

/*
 * This is a comment with a whitespace at the beginning
 */

/*
This comment has a newline
*/

:::

::: correct

/* eslint spaced-comment: ["error", "always"] */

/**
* I am jsdoc
*/

:::

never

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

::: incorrect

/*eslint spaced-comment: ["error", "never"]*/

// This is a comment with a whitespace at the beginning

/* This is a comment with a whitespace at the beginning */

/* \nThis is a comment with a whitespace at the beginning */

:::

::: incorrect

/*eslint spaced-comment: ["error", "never", { "block": { "balanced": true } }]*/
/*This is a comment with whitespace at the end */

:::

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

::: correct

/*eslint spaced-comment: ["error", "never"]*/

/*This is a comment with no whitespace at the beginning */

:::

::: correct

/*eslint spaced-comment: ["error", "never"]*/

/**
* I am jsdoc
*/

:::

exceptions

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

::: incorrect

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-"] } }] */

//--------------
// Comment block
//--------------

:::

::: incorrect

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */

//------++++++++
// Comment block
//------++++++++

:::

::: incorrect

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-", "+"] }] */

/*------++++++++*/
/* Comment block */
/*------++++++++*/

:::

::: incorrect

/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-+"] } }] */

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

:::

::: incorrect

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["*"] } }] */

/******** COMMENT *******/

:::

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

::: correct

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-"] }] */

//--------------
// Comment block
//--------------

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "line": { "exceptions": ["-"] } }] */

//--------------
// Comment block
//--------------

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "exceptions": ["*"] }] */

/****************
 * Comment block
 ****************/

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "exceptions": ["-+"] }] */

//-+-+-+-+-+-+-+
// Comment block
//-+-+-+-+-+-+-+

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["-+"] } }] */

/*-+-+-+-+-+-+-+*/
// Comment block
/*-+-+-+-+-+-+-+*/

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "block": { "exceptions": ["*"] } }] */

/***************/

/********
COMMENT
*******/

:::

markers

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

::: incorrect

/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */

///This is a comment with a marker but without whitespace

:::

::: incorrect

/*eslint spaced-comment: ["error", "always", { "block": { "markers": ["!"], "balanced": true } }]*/
/*! This is a comment with a marker but without whitespace at the end*/

:::

::: incorrect

/*eslint spaced-comment: ["error", "never", { "block": { "markers": ["!"], "balanced": true } }]*/
/*!This is a comment with a marker but with whitespace at the end */

:::

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

::: correct

/* eslint spaced-comment: ["error", "always", { "markers": ["/"] }] */

/// This is a comment with a marker

:::

::: correct

/*eslint spaced-comment: ["error", "never", { "markers": ["!<"] }]*/

//!<this is a line comment with marker block subsequent lines are ignored></this>

:::

::: correct

/* eslint spaced-comment: ["error", "always", { "markers": ["global"] }] */

/*global ABC*/

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

    MathJax.typesetPromise()

Close

---

title: no-undef ruletype: problem handledbytypescript: true relatedrules: - no-global-assign

- no-redeclare

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, or specified in the [globals key in the configuration file](../use/configure/language-options#using-configuration-files-1). A common use case for these is if you intentionally use globals that are defined elsewhere (e.g. in a script sourced from HTML).

Examples of incorrect code for this rule:

::: incorrect

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

var foo = someFunction();
var bar = a + 1;

:::

Examples of correct code for this rule with global declaration:

::: correct

/*global someFunction, a*/
/*eslint no-undef: "error"*/

var foo = someFunction();
var bar = a + 1;

:::

Note that this rule does not disallow assignments to read-only global variables. See [no-global-assign](no-global-assign) if you also want to disallow those assignments.

This rule also does not disallow redeclarations of global variables. See [no-redeclare](no-redeclare) if you also want to disallow those redeclarations.

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:

::: correct

/*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:

::: incorrect

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

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

:::

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

::: correct

/*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](../use/configure/language-options#specifying-environments). A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

::: correct

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

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

:::

Node.js

Examples of correct code for this rule with node environment:

::: correct

/*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. Source: http://eslint.org/docs/rules/

```bash

Close

MD031 - Fenced code blocks should be surrounded by blank lines

Tags: code, blank_lines

Aliases: blanks-around-fences

This rule is triggered when fenced code blocks are either not preceded or not followed by a blank line:

Some text
```
Code block
```

```
Another code block
```
Some more text

To fix this, ensure that all fenced code blocks have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

```
Code block
```

```
Another code block
```

Some more text

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse fenced code blocks that don't have blank lines before and after them.

} catch (e) {

Close

---

title: no-empty ruletype: suggestion relatedrules:

- no-empty-function

Empty block statements, while not technically errors, usually occur due to refactoring that wasn't completed. They can cause confusion when reading code.

Rule Details

This rule disallows empty block statements. This rule ignores block statements which contain a comment (for example, in an empty catch or finally block of a try statement to indicate that execution should continue regardless of errors).

Examples of incorrect code for this rule:

::: incorrect

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

if (foo) {
}

while (foo) {
}

switch(foo) {
}

try {
    doSomething();
} catch(ex) {

} finally {

}

:::

Examples of correct code for this rule:

::: correct

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

if (foo) {
    // empty
}

while (foo) {
    /* empty */
}

try {
    doSomething();
} catch (ex) {
    // continue regardless of error
}

try {
    doSomething();
} finally {
    /* continue regardless of error */
}

:::

Options

This rule has an object option for exceptions:

• "allowEmptyCatch": true allows empty catch clauses (that is, which do not contain a comment)

allowEmptyCatch

Examples of additional correct code for this rule with the { "allowEmptyCatch": true } option:

::: correct

/* eslint no-empty: ["error", { "allowEmptyCatch": true }] */
try {
    doSomething();
} catch (ex) {}

try {
    doSomething();
}
catch (ex) {}
finally {
    /* continue regardless of error */
}

:::

When Not To Use It

If you intentionally use empty block statements then you can disable this rule. Source: http://eslint.org/docs/rules/

  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/

  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/

{"data":{"listDirectory":{"repository":{"tree":{"blobs":{"edges":[]},"trees":{"edges":[{"node":{"name":"data","type":"tree"}},{"node":{"name":"digital twins","type":"tree"}},{"node":{"name":"functions","type":"tree"}},{"node":{"name":"models","type":"tree"}},{"node":{"name":"tools","type":"tree"}}]}}}}}}

Close

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

```/workspace/examples/digital_twins/drobotti_rmqfmu/target```.

Close

MD031 - Fenced code blocks should be surrounded by blank lines

Tags: code, blank_lines

Aliases: blanks-around-fences

This rule is triggered when fenced code blocks are either not preceded or not followed by a blank line:

Some text
```
Code block
```

```
Another code block
```
Some more text

To fix this, ensure that all fenced code blocks have a blank line both before and after (except where the block is at the beginning or end of the document):

Some text

```
Code block
```

```
Another code block
```

Some more text

Rationale: Aside from aesthetic reasons, some parsers, including kramdown, will not parse fenced code blocks that don't have blank lines before and after them.

const log = console.log;

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/

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/

  document$.subscribe(() => {

Close

---

title: no-undef ruletype: problem handledbytypescript: true relatedrules: - no-global-assign

- no-redeclare

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, or specified in the [globals key in the configuration file](../use/configure/language-options#using-configuration-files-1). A common use case for these is if you intentionally use globals that are defined elsewhere (e.g. in a script sourced from HTML).

Examples of incorrect code for this rule:

::: incorrect

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

var foo = someFunction();
var bar = a + 1;

:::

Examples of correct code for this rule with global declaration:

::: correct

/*global someFunction, a*/
/*eslint no-undef: "error"*/

var foo = someFunction();
var bar = a + 1;

:::

Note that this rule does not disallow assignments to read-only global variables. See [no-global-assign](no-global-assign) if you also want to disallow those assignments.

This rule also does not disallow redeclarations of global variables. See [no-redeclare](no-redeclare) if you also want to disallow those redeclarations.

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:

::: correct

/*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:

::: incorrect

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

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

:::

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

::: correct

/*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](../use/configure/language-options#specifying-environments). A few examples are given below.

browser

Examples of correct code for this rule with browser environment:

::: correct

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

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

:::

Node.js

Examples of correct code for this rule with node environment:

::: correct

/*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. Source: http://eslint.org/docs/rules/

  - common: 

Close

MD009 - Trailing spaces

Tags: whitespace

Aliases: no-trailing-spaces

Parameters: br_spaces (number; default: 0)

This rule is triggered on any lines that end with whitespace. To fix this, find the line that is triggered and remove any trailing spaces from the end.

The brspaces parameter allows an exception to this rule for a specific amount of trailing spaces used to insert an explicit line break/br element. For example, set brspaces to 2 to allow exactly 2 spaces at the end of a line.

Note: you have to set brspaces to 2 or higher for this exception to take effect - you can't insert a br element with just a single trailing space, so if you set brspaces to 1, the exception will be disabled, just as if it was set to the default of 0.

  - common: 

Close

MD009 - Trailing spaces

Tags: whitespace

Aliases: no-trailing-spaces

Parameters: br_spaces (number; default: 0)

This rule is triggered on any lines that end with whitespace. To fix this, find the line that is triggered and remove any trailing spaces from the end.

The brspaces parameter allows an exception to this rule for a specific amount of trailing spaces used to insert an explicit line break/br element. For example, set brspaces to 2 to allow exactly 2 spaces at the end of a line.

Note: you have to set brspaces to 2 or higher for this exception to take effect - you can't insert a br element with just a single trailing space, so if you set brspaces to 1, the exception will be disabled, just as if it was set to the default of 0.

   "query":"query {\n  listDirectory(path: \".\") {\n    repository {\n      tree {\n        blobs {\n          edges {\n            node {\n              name\n              type\n            }\n          }\n        }\n        trees {\n          edges {\n            node {\n              name\n              type\n            }\n          }\n        }\n      }\n    }\n  }\n}"

Close

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.

{"data":{"readFile":{"repository":{"blobs":{"nodes":[{"name":"welcome.txt","rawBlob":"hello world","rawTextBlob":"hello world"}]}}}}}

Close

MD013 - Line length

Tags: line_length

Aliases: line-length Parameters: linelength, codeblocks, tables (number; default 80, boolean; default true)

This rule is triggered when there are lines that are longer than the configured line length (default: 80 characters). To fix this, split the line up into multiple lines.

This rule has an exception where there is no whitespace beyond the configured line length. This allows you to still include items such as long URLs without being forced to break them in the middle.

You also have the option to exclude this rule for code blocks and tables. To do this, set the code_blocks and/or tables parameters to false.

Code blocks are included in this rule by default since it is often a requirement for document readability, and tentatively compatible with code rules. Still, some languages do not lend themselves to short lines.