...
15 | 
17 | ```
18 |
19 | ### Fail
20 |
21 | ```jsx
22 |
23 |
24 | ```
25 |
26 | ## Accessibility guidelines
27 |
28 | - [WAI-ARIA Roles model](https://www.w3.org/TR/wai-aria-1.0/roles)
29 |
30 | ### Resources
31 |
32 | - [MDN WAI-ARIA Roles](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Roles)
33 |
--------------------------------------------------------------------------------
/docs/description/jsx-a11y_scope.md:
--------------------------------------------------------------------------------
1 | # jsx-a11y/scope
2 |
3 | 💼 This rule is enabled in the following configs: ☑️ `recommended`, 🔒 `strict`.
4 |
5 |
6 |
7 | The `scope` prop should be used only on `` elements.
8 |
9 | ## Rule details
10 |
11 | This rule takes no arguments.
12 |
13 | ### Succeed
14 | ```jsx
15 | `;
16 | html``;
17 | html``;
18 | html``;
19 | ```
20 |
21 | The following patterns are not warnings:
22 |
23 | ```ts
24 | html``;
25 | ```
26 |
27 | ## When Not To Use It
28 |
29 | If you don't care about potential parsing errors, then you will not
30 | need this rule.
31 |
--------------------------------------------------------------------------------
/docs/description/lit_ban-attributes.md:
--------------------------------------------------------------------------------
1 | # Disallows a set of attributes from being used (ban-attributes)
2 |
3 | You may prefer to disallow some attributes for various reasons in templates,
4 | this simply allows you to create such a denylist.
5 |
6 | ## Rule Details
7 |
8 | This rule disallows a list of attributes within templates.
9 |
10 | The following patterns are considered warnings:
11 |
12 | ```ts
13 | /*eslint lit/ban-attributes: ["error", "attr"] */
14 | html``;
15 | ```
16 |
17 | The following patterns are not warnings:
18 |
19 | ```ts
20 | html``;
21 | ```
22 |
23 | ## When Not To Use It
24 |
25 | If you don't have any particular attributes you wish to disallow, you do not
26 | need this rule.
27 |
--------------------------------------------------------------------------------
/docs/description/lit_no-duplicate-template-bindings.md:
--------------------------------------------------------------------------------
1 | # Disallows duplicate names in template bindings (no-duplicate-template-bindings)
2 |
3 | Binding a property or attribute multiple times results in the previous
4 | values being overwritten, thus making them useless.
5 |
6 | ## Rule Details
7 |
8 | This rule disallows binding the same property multiple times in templates.
9 |
10 | The following patterns are considered warnings:
11 |
12 | ```ts
13 | html``;
14 | html``;
15 | ```
16 |
17 | The following patterns are not warnings:
18 |
19 | ```ts
20 | html``;
21 | ```
22 |
23 | ## When Not To Use It
24 |
25 | If you don't care about repeated bindings, then you will not need this rule.
26 |
--------------------------------------------------------------------------------
/docs/description/lit_no-invalid-html.md:
--------------------------------------------------------------------------------
1 | # Disallows invalid HTML in templates (no-invalid-html)
2 |
3 | Templates should all contain valid HTML, if any, as it is expected
4 | to be parsed as part of rendering.
5 |
6 | ## Rule Details
7 |
8 | This rule disallows invalid HTML in templates.
9 |
10 | The following patterns are considered warnings:
11 |
12 | ```ts
13 | html``;
22 | html``;
23 | ```
24 |
25 | ## When Not To Use It
26 |
27 | If you wish to bind the `value` attribute, you will not need this rule.
28 |
--------------------------------------------------------------------------------
/docs/description/lodash-fp_no-extraneous-args.md:
--------------------------------------------------------------------------------
1 | # No extraneous arguments to methods with a fixed arity
2 |
3 | In `lodash/fp`, most methods have a fixed number of arguments, often ignoring optional arguments available in vanilla Lodash.
4 | For instance, in vanilla Lodash, [`_.get`] accepts a third parameter that serves as the default value, which gets ignored in `lodash/fp` (hint: use the `_.getOr` method instead which exists for that purpose). The rule reports instances where too many arguments are passed to a method.
5 |
6 | ### Fail
7 |
8 | ```js
9 | _.get(path, defaultValue, object);
10 | _.find(iteratee, object, extraneous);
11 | ```
12 |
13 | ### Pass
14 |
15 | ```js
16 | _.get(path, object);
17 | _.getOr(path, defaultValue, object);
18 | _.find(iteratee, object);
19 | ```
20 |
21 | [`_.get`]: https://lodash.com/docs#get
22 |
--------------------------------------------------------------------------------
/docs/description/lodash-fp_no-extraneous-partials.md:
--------------------------------------------------------------------------------
1 | # No extraneous partials
2 |
3 | In `lodash/fp`, most methods are curried. This means there are multiple ways to
4 | call a `lodash/fp` method. Where possible you should always call the method
5 | directly, to avoid the creation of any intermediate partals.
6 |
7 | ### Fail
8 |
9 | ```js
10 | _.get(path)(object);
11 | _.getOr(path)(defaultValue)(object);
12 | _.find(iteratee)(object);
13 | ```
14 |
15 | ### Pass
16 |
17 | ```js
18 | _.get(path, object);
19 | _.getOr(path, defaultValue, object);
20 | _.find(iteratee, object);
21 | _.flow(_.get(path), _.map(fn))(object);
22 | ```
23 |
--------------------------------------------------------------------------------
/docs/description/lodash-fp_no-single-composition.md:
--------------------------------------------------------------------------------
1 | # Enforce at least two methods arguments for composition methods
2 |
3 | Giving one argument to composition methods like [`_.flow`](https://lodash.com/docs#flow) and [`_.compose`](https://lodash.com/docs#flowRight) is useless, as `_.flow(fn)(x)` is the same as calling `fn(x)`.
4 |
5 | ### Fail
6 |
7 | ```js
8 | import _, {flow} from 'lodash/fp';
9 |
10 | flow(fn)(x);
11 | _.flow(fn)(x);
12 | ```
13 |
14 | ### Pass
15 |
16 | ```js
17 | import _, {flow} from 'lodash/fp';
18 |
19 | flow(fn1, fn2)(x);
20 | _.flow(fn1, fn2)(x);
21 | ```
22 |
--------------------------------------------------------------------------------
/docs/description/lodash-fp_use-fp.md:
--------------------------------------------------------------------------------
1 | # Use lodash/fp instead of Lodash
2 |
3 | This rule disallows the use of vanilla Lodash in your code. The aim for this is to avoid mixing both vanilla and fp Lodash in your codebase.
4 |
5 | ### Fail
6 |
7 | ```js
8 | import _ from 'lodash';
9 | import _ from 'lodash/bindAll';
10 |
11 | const _ = require('lodash');
12 | const _ = require('lodash/bindAll');
13 | ```
14 |
15 | ### Pass
16 |
17 | ```js
18 | import _ from 'lodash/fp';
19 | import _ from 'lodash/fp/bindAll';
20 |
21 | const _ = require('lodash/fp');
22 | const _ = require('lodash/fp/bindAll');
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/lodash_collection-return.md:
--------------------------------------------------------------------------------
1 | # Collection Return Statement
2 |
3 | When using a Lodash collection method that isn't forEach, the iteratee should return a value, otherwise it could result in either unclear code or unexpected results.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _.map(arr, function(x) { console.log(x); });
14 |
15 | _.some(arr, function(x) { if (x.a) {f(x); });
16 |
17 | _.every(collection, x => { f(x); });
18 |
19 | ```
20 |
21 | The following patterns are not considered warnings:
22 |
23 | ```js
24 |
25 | _.map(x => x + 1);
26 |
27 | _.forEach(arr, function(a) { console.log(a); });
28 |
29 | ```
30 |
--------------------------------------------------------------------------------
/docs/description/lodash_no-commit.md:
--------------------------------------------------------------------------------
1 | # No Commit
2 |
3 | Using `_.prototype.commit()` at the end of the chain executes the chain but doesn't unwrap the value.
4 | In most cases, this means that `_.prototype.value()` would be preferable.
5 |
6 | ## Rule Details
7 |
8 | This rule takes no arguments.
9 |
10 | The following patterns are considered warnings:
11 |
12 | ```js
13 |
14 | _(a).map(f).filter(g).commit();
15 |
16 | ```
17 |
18 | The following patterns are not considered warnings:
19 |
20 | ```js
21 |
22 | _(a).map(f).filter(g).value();
23 |
24 | ```
25 |
26 |
27 | ## When Not To Use It
28 |
29 | If you do not want to disallow using `commit`, you should not use this rule.
--------------------------------------------------------------------------------
/docs/description/lodash_no-double-unwrap.md:
--------------------------------------------------------------------------------
1 | # Unwrapping an already finished chain (no-double-unwrap)
2 |
3 | Some Lodash and wrapper methods remove the wrapper from the chain, e.g. `reduce`, `max` or `join`.
4 | In these cases, the use of `.value()` would most likely cause an error.
5 |
6 |
7 | ## Rule Details
8 |
9 | This rule takes no arguments.
10 |
11 | The following patterns are considered warnings:
12 |
13 | ```js
14 | var x = _(a).reduce(f).value();
15 |
16 |
17 | ```
18 |
19 | The following patterns are not considered warnings:
20 |
21 | ```js
22 | var x = _(a).map(f).reduce(g);
23 |
24 | var x = _(a).map(f).value();
25 |
26 | var x = _.chain(a).map(f).reduce(g).value();
27 | ```
28 |
29 |
30 | ## When Not To Use It
31 |
32 | If you don't want to check for this possible error, or if the objects you pass to Lodash have a `value`, `run` or `toJSON` method.
33 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-compact.md:
--------------------------------------------------------------------------------
1 | # Prefer compact
2 |
3 | When using _.filter with an identity or boolean casting , it could improve readability by switching to _.compact
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _(arr).map(f).filter(function(x) {return x}),
14 |
15 | _.filter(arr, function(x) { return !!x})
16 | ```
17 |
18 | The following patterns are not considered warnings:
19 |
20 | ```js
21 |
22 | var x = _.filter(arr, function(x) {return !x.a && p});
23 |
24 | var x = _.filter(arr, function(x) {return f(x) || g(x)});
25 |
26 | var x = _.compact(arr);
27 | ```
28 |
29 |
30 | ## When Not To Use It
31 |
32 | If you do not want to enforce using `_.compact`, you should not use this rule.
33 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-find.md:
--------------------------------------------------------------------------------
1 | # Prefer find
2 |
3 | When using _.filter and accessing the first or last result, you should probably use `_.find` or `_.findLast`, respectively.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 | const x = _.filter(a, f)[0];
13 | ```
14 |
15 | ```js
16 | const x = _.head(_.filter(a, f));
17 | ```
18 |
19 | ```js
20 | const x = _(a)
21 | .filter(f)
22 | .head()
23 | ```
24 |
25 | ```js
26 | const x = _.last(_.filter(a, f));
27 | ```
28 |
29 | ```js
30 | const x = _.head(_.reject(a, f));
31 | ```
32 | The following patterns are not considered warnings:
33 |
34 | ```js
35 | const x = _.filter(a, f);
36 | ```
37 |
38 | ```js
39 | const x = _.filter(a, f)[3];
40 | ```
41 |
42 | ```js
43 | const x = _.find(a, f);
44 | ```
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-get.md:
--------------------------------------------------------------------------------
1 | # Prefer get
2 |
3 | When writing an expression like `a && a.b && a.b.c` just to make sure the path exists, it is more readable to use the functions `_.get`, `_.set` and `_.has` instead.
4 |
5 | ## Rule Details
6 |
7 | This rule takes one argument - the minimal depth (default is 3).
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | var isThree = a && a.b && a.b.c === 3;
14 |
15 | if (a && a.b && a.b.c) {
16 | // ...
17 | }
18 |
19 | ```
20 |
21 | The following patterns are not considered warnings:
22 |
23 | ```js
24 |
25 | var isThree = _.get(a, 'b.c') === 3;
26 |
27 | if (_.has(a, 'b.c')) {
28 | // ...
29 | }
30 |
31 | ```
32 |
33 |
34 | ## When Not To Use It
35 |
36 | If you do not want to enforce using `get`, you should not use this rule.
37 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-immutable-method.md:
--------------------------------------------------------------------------------
1 | # Prefer immutable methods
2 | Prefer a method that doesn't mutate the arguments when available.
3 |
4 | ## Rule Details
5 |
6 | This rule takes no arguments
7 |
8 | The following patterns are considered warnings:
9 |
10 | ```js
11 | _.pull(arr, value)
12 | ```
13 |
14 | ```js
15 | const a = _.remove(arr, fn);
16 | ```
17 |
18 | The following patterns are not considered warnings:
19 |
20 | ```js
21 | const a = _.without(arr, value);
22 | ```
23 |
24 | ```js
25 | const a = _.filter(arr, fn);
26 | ```
27 |
28 |
29 | ## When Not To Use It
30 | If you do not want to enforce using methods that do not mutate the arguments when available, do not enable this rule.
31 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-is-nil.md:
--------------------------------------------------------------------------------
1 | # Prefer _.isNil
2 |
3 | When checking that a value is undefined or null (but not false or ''), it is more concise to use _.isNil instead.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 | var t = !_.isNull(x) && !_.isUndefined(x);
13 |
14 | var t = x === undefined || x === null;
15 | ```
16 |
17 | The following patterns are not considered warnings:
18 |
19 | ```js
20 |
21 | var t = _.isNil(x);
22 |
23 | var t = _.isUndefined(x) || _.isNull(y);
24 | ```
25 |
26 |
27 | ## When Not To Use It
28 | ##### This rule is only relevant for Lodash 4. If you don't use Lodash 4, you should not use this rule.
29 | If you do not want to enforce using `_.isNil`, and prefer using specific checks instead.
30 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-map.md:
--------------------------------------------------------------------------------
1 | # Prefer map
2 |
3 | When using `_.forEach` that pushes into an array, it could improve readability to use `_.map` instead.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _.forEach(arr, function(x) { newArr.push(f(x))})
14 |
15 | ```
16 |
17 | The following patterns are not considered warnings:
18 |
19 | ```js
20 |
21 | _.forEach(arr, function(x) { if (x.a) { a.push(x) }})
22 | ```
23 |
24 |
25 | ## When Not To Use It
26 |
27 | If you do not want to enforce using `map`, you should not use this rule.
28 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-noop.md:
--------------------------------------------------------------------------------
1 | # Prefer noop
2 |
3 | When defining an empty function (e.g. for callbacks) it can be more readable to use `_.noop` instead
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | functionWithCallback(function(){});
14 |
15 | const emptyFunction = ()=> {};
16 |
17 | ```
18 |
19 | The following patterns are not considered warnings:
20 |
21 | ```js
22 |
23 | functionWithCallback(function(x){return x + 1});
24 |
25 | const sqr = x => x * x;
26 |
27 | ```
28 |
29 |
30 | ## When Not To Use It
31 |
32 | If you do not want to enforce using `_.noop`, you should not use this rule.
33 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-over-quantifier.md:
--------------------------------------------------------------------------------
1 | # Prefer Over-Quantifier
2 |
3 | When using methods that select according to a set of conditions with 'some' and 'every' behavior, it's possible to pass an iteratee created by overSome and overEvery
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 | var t = _.filter(a, function(x) { return f(x) && g(x); })
13 |
14 | 'var t = _.filter(a, x => f(x) || g(x) || h(x))'
15 |
16 | ```
17 |
18 | The following patterns are not considered warnings:
19 |
20 | ```js
21 | var t = _.filter(a, _.overSome([f, g, h]);
22 |
23 | ```
24 | ## When Not To Use It
25 | ##### This rule is only relevant for Lodash 4. If you don't use Lodash 4, you should not use this rule.
26 | If you do not want to enforce using `_.overSome` and `_.overEvery`, do not use this rule.
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-startswith.md:
--------------------------------------------------------------------------------
1 | # Prefer _.startsWith
2 |
3 | To check that a string starts with a substring or an array starts with an item, it's better to use `_.startsWith` than comparing the index to zero.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | var x = a.indexOf(b) === 0;
14 |
15 | if (str.indexOf('@@') !== 0) {}
16 |
17 | ```
18 |
19 | The following patterns are not considered warnings:
20 |
21 | ```js
22 |
23 | var x = a.indexOf(b);
24 |
25 | if (str.indexOf('@@') > 0) {}
26 |
27 | ```
28 |
29 |
30 | ## When Not To Use It
31 |
32 | If you do not want to use Lodash to check that an array or a string starts with an item, do not use this rule.
33 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-thru.md:
--------------------------------------------------------------------------------
1 | # Prefer thru
2 |
3 | When starting a chain with an initial value that contains a function call on a single argument, it could improve readability to move that function to the chain itself with `thru`.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _(f(x)).map(g).reduce(h);
14 |
15 | _.chain(f1(f2(x).split(''))).map(f).reduce(g).value();
16 |
17 | ```
18 |
19 | The following patterns are not considered warnings:
20 |
21 | ```js
22 |
23 | _(str).thru(f).map(h).reduce(g);
24 |
25 | ```
26 |
27 |
28 | ## When Not To Use It
29 |
30 | If you do not want to enforce using `thru`, you should not use this rule.
31 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-times.md:
--------------------------------------------------------------------------------
1 | # Prefer _.times
2 |
3 | When using `_.map` in which the iteratee does not have any arguments, it's better to use `_.times`.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _.map(arr, function() { return 7});
14 |
15 | _(a).map(() => 7).value();
16 |
17 | _.map(Array(10), function() {return f(y)});
18 |
19 | import f from 'lodash/map'; f(arr, () => 0)
20 |
21 | ```
22 |
23 | The following patterns are not considered warnings:
24 |
25 | ```js
26 |
27 | _.times(arr.length, _.constant(7));
28 |
29 | _.map(arr, function(x) {return x * x;});
30 |
31 | ```
32 |
33 |
34 | ## When Not To Use It
35 |
36 | If you do not want to enforce always using `times` when not using the arguments, you should not use this rule.
37 |
--------------------------------------------------------------------------------
/docs/description/lodash_prefer-wrapper-method.md:
--------------------------------------------------------------------------------
1 | # Prefer wrapper method
2 |
3 | When starting a chain with an initial value that contains a call to an array or string method, it could be better to move that method to the chain itself.
4 |
5 | ## Rule Details
6 |
7 | This rule takes no arguments.
8 |
9 | The following patterns are considered warnings:
10 |
11 | ```js
12 |
13 | _(str.split(' ')).map(f).reduce(g);
14 |
15 | _.chain(str.split(' ')).map(f).reduce(g).value();
16 |
17 | ```
18 |
19 | The following patterns are not considered warnings:
20 |
21 | ```js
22 |
23 | _(str).split(' ').map(f).reduce(g);
24 |
25 | _.chain(str).split(' ').map(f).reduce(g).value();
26 | ```
27 |
28 |
29 | ## When Not To Use It
30 |
31 | If you do not want to enforce using wrapper methods, you should not use this rule.
32 |
--------------------------------------------------------------------------------
/docs/description/lodash_preferred-alias.md:
--------------------------------------------------------------------------------
1 | # Preferred Alias
2 |
3 | Some Lodash methods have one or more aliases, which can lead to inconsistent code and decrease readability.
4 |
5 | ## Rule Details
6 |
7 | This rule takes one argument - an optional options object. This object can have one key:
8 | - `ignoreMethods`: contains an array of method names that should not be reported on.
9 |
10 | The following patterns are considered warnings:
11 |
12 | ```js
13 | _.each(users, f);
14 | ```
15 |
16 | The following patterns are not considered warnings:
17 |
18 | ```js
19 | _.forEach(users, f);
20 | ```
21 |
22 |
23 | ## When Not To Use It
24 |
25 | If you do not want to enforce preferred alias, then you can disable this rule.
26 |
--------------------------------------------------------------------------------
/docs/description/meteor_no-template-parent-data.md:
--------------------------------------------------------------------------------
1 | # Avoid accessing template parent data (no-template-parent-data)
2 |
3 | When making children aware of their parents data context, they are tightly integrated and hard to reuse.
4 | Changing the parent can lead to unintended errors in the child.
5 | Passing down the properties explicitly avoids this issue.
6 |
7 |
8 | ## Rule Details
9 |
10 | This rule aims to ensure child components are unaware of their parents.
11 |
12 | The following patterns are considered warnings:
13 |
14 | ```js
15 |
16 | Template.parentData()
17 | Template.parentData(0)
18 | Template.parentData(1)
19 | Template.parentData(foo)
20 |
21 | ```
22 |
23 | The following patterns are not warnings:
24 |
25 | ```js
26 |
27 | Template.currentData()
28 |
29 | ```
30 |
31 | ## Further Reading
32 |
33 | - http://docs.meteor.com/#/full/template_parentdata
34 |
--------------------------------------------------------------------------------
/docs/description/no-delete-var.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: no-delete-var
3 | rule_type: suggestion
4 | ---
5 |
6 |
7 |
8 | The purpose of the `delete` operator is to remove a property from an object. Using the `delete` operator on a variable might lead to unexpected behavior.
9 |
10 | ## Rule Details
11 |
12 | This rule disallows the use of the `delete` operator on variables.
13 |
14 | If ESLint parses code in strict mode, the parser (instead of this rule) reports the error.
15 |
16 | Examples of **incorrect** code for this rule:
17 |
18 | ::: incorrect { "sourceType": "script" }
19 |
20 | ```js
21 | /*eslint no-delete-var: "error"*/
22 |
23 | var x;
24 | delete x;
25 | ```
26 |
27 | :::
28 |
--------------------------------------------------------------------------------
/docs/description/no-script-url.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: no-script-url
3 | rule_type: suggestion
4 | further_reading:
5 | - https://stackoverflow.com/questions/13497971/what-is-the-matter-with-script-targeted-urls
6 | ---
7 |
8 |
9 | Using `javascript:` URLs is considered by some as a form of `eval`. Code passed in `javascript:` URLs has to be parsed and evaluated by the browser in the same way that `eval` is processed.
10 |
11 | ## Rule Details
12 |
13 | Examples of **incorrect** code for this rule:
14 |
15 | ::: incorrect
16 |
17 | ```js
18 | /*eslint no-script-url: "error"*/
19 |
20 | location.href = "javascript:void(0)";
21 |
22 | location.href = `javascript:void(0)`;
23 | ```
24 |
25 | :::
26 |
27 | ## Compatibility
28 |
29 | * **JSHint**: This rule corresponds to `scripturl` rule of JSHint.
30 |
--------------------------------------------------------------------------------
/docs/description/no-spaced-func.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: no-spaced-func
3 | rule_type: layout
4 | ---
5 |
6 |
7 |
8 | This rule was **deprecated** in ESLint v3.3.0 and replaced by the [func-call-spacing](func-call-spacing) rule.
9 |
10 | While it's possible to have whitespace between the name of a function and the parentheses that execute it, such patterns tend to look more like errors.
11 |
12 | ## Rule Details
13 |
14 | This rule disallows spacing between function identifiers and their applications.
15 |
16 | Examples of **incorrect** code for this rule:
17 |
18 | ::: incorrect
19 |
20 | ```js
21 | /*eslint no-spaced-func: "error"*/
22 |
23 | fn ()
24 |
25 | fn
26 | ()
27 | ```
28 |
29 | :::
30 |
31 | Examples of **correct** code for this rule:
32 |
33 | ::: correct
34 |
35 | ```js
36 | /*eslint no-spaced-func: "error"*/
37 |
38 | fn()
39 | ```
40 |
41 | :::
42 |
--------------------------------------------------------------------------------
/docs/description/nuxt_require-func-head.md:
--------------------------------------------------------------------------------
1 | # nuxt/require-func-head
2 |
3 | > enforce `head` property in component to be a function.
4 |
5 | ## Rule Details
6 |
7 | This rule is enforcing `head` property in component to be a function.
8 |
9 | Examples of **incorrect** code for this rule:
10 |
11 | ```js
12 |
13 | export default {
14 | head: {
15 | title: "My page"
16 | }
17 | }
18 |
19 | ```
20 |
21 | Examples of **correct** code for this rule:
22 |
23 | ```js
24 |
25 | export default {
26 | head() {
27 | return {
28 | title: "My page"
29 | }
30 | }
31 | }
32 |
33 | ```
34 |
35 | ## :mag: Implementation
36 |
37 | - [Rule source](https://github.com/nuxt/eslint-plugin-nuxt/tree/master/lib/rules/require-func-head.js)
38 | - [Test source](https://github.com/nuxt/eslint-plugin-nuxt/tree/master/lib/rules/__tests__/require-func-head.test.js)
39 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-element-handle.md:
--------------------------------------------------------------------------------
1 | ## Disallow usage of element handles (`no-element-handle`)
2 |
3 | Disallow the creation of element handles with `page.$` or `page.$$`.
4 |
5 | ## Rule Details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```javascript
10 | // Element Handle
11 | const buttonHandle = await page.$('button')
12 | await buttonHandle.click()
13 |
14 | // Element Handles
15 | const linkHandles = await page.$$('a')
16 | ```
17 |
18 | Example of **correct** code for this rule:
19 |
20 | ```javascript
21 | const buttonLocator = page.locator('button')
22 | await buttonLocator.click()
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-eval.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of `page.$eval` and `page.$$eval` (`no-eval`)
2 |
3 | ## Rule Details
4 |
5 | Examples of **incorrect** code for this rule:
6 |
7 | ```javascript
8 | const searchValue = await page.$eval('#search', (el) => el.value)
9 |
10 | const divCounts = await page.$$eval(
11 | 'div',
12 | (divs, min) => divs.length >= min,
13 | 10,
14 | )
15 |
16 | await page.$eval('#search', (el) => el.value)
17 | await page.$$eval('#search', (el) => el.value)
18 | ```
19 |
20 | Example of **correct** code for this rule:
21 |
22 | ```javascript
23 | await page.locator('button').evaluate((node) => node.innerText)
24 | await page.locator('div').evaluateAll((divs, min) => divs.length >= min, 10)
25 | ```
26 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-force-option.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of the `{ force: true }` option (`no-force-option`)
2 |
3 | ## Rule Details
4 |
5 | Examples of **incorrect** code for this rule:
6 |
7 | ```javascript
8 | await page.locator('button').click({ force: true })
9 | await page.locator('check').check({ force: true })
10 | await page.locator('input').fill('something', { force: true })
11 | ```
12 |
13 | Examples of **correct** code for this rule:
14 |
15 | ```javascript
16 | await page.locator('button').click()
17 | await page.locator('check').check()
18 | await page.locator('input').fill('something')
19 | ```
20 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-get-by-title.md:
--------------------------------------------------------------------------------
1 | ## Disallow using `getByTitle()` (`no-get-by-title`)
2 |
3 | The HTML `title` attribute does not provide a fully accessible tooltip for
4 | elements so relying on it to identify elements can hide accessibility issues in
5 | your code. This rule helps to prevent that by disallowing use of the
6 | `getByTitle` method.
7 |
8 | ## Rule Details
9 |
10 | Example of **incorrect** code for this rule:
11 |
12 | ```javascript
13 | await page.getByTitle('Delete product').click()
14 | ```
15 |
16 | Example of **correct** code for this rule:
17 |
18 | ```javascript
19 | await page.getByRole('button', { name: 'Delete product' }).click()
20 | ```
21 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-nested-step.md:
--------------------------------------------------------------------------------
1 | # Disallow nested `test.step()` methods (`no-nested-step`)
2 |
3 | Nesting `test.step()` methods can make your tests difficult to read.
4 |
5 | ## Rule Details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```javascript
10 | test('foo', async () => {
11 | await test.step('step1', async () => {
12 | await test.step('nest step', async () => {
13 | await expect(true).toBe(true)
14 | })
15 | })
16 | })
17 | ```
18 |
19 | Examples of **correct** code for this rule:
20 |
21 | ```javascript
22 | test('foo', async () => {
23 | await test.step('step1', async () => {
24 | await expect(true).toBe(true)
25 | })
26 | await test.step('step2', async () => {
27 | await expect(true).toBe(true)
28 | })
29 | })
30 | ```
31 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-networkidle.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of the `networkidle` option (`no-networkidle`)
2 |
3 | Using `networkidle` is discouraged in favor of using
4 | [web first assertions](https://playwright.dev/docs/best-practices#use-web-first-assertions).
5 |
6 | ## Rule Details
7 |
8 | Examples of **incorrect** code for this rule:
9 |
10 | ```javascript
11 | await page.waitForLoadState('networkidle')
12 | await page.waitForURL('...', { waitUntil: 'networkidle' })
13 | await page.goto('...', { waitUntil: 'networkidle' })
14 | ```
15 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-nth-methods.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of `nth` methods (`no-nth-methods`)
2 |
3 | This rule prevents the usage of `nth` methods (`first()`, `last()`, and
4 | `nth()`). These methods can be prone to flakiness if the DOM structure changes.
5 |
6 | ## Rule Details
7 |
8 | Examples of **incorrect** code for this rule:
9 |
10 | ```javascript
11 | page.locator('button').first()
12 | page.locator('button').last()
13 | page.locator('button').nth(3)
14 | ```
15 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-page-pause.md:
--------------------------------------------------------------------------------
1 | ## Disallow using `page.pause` (`no-page-pause`)
2 |
3 | Prevent usage of `page.pause()`.
4 |
5 | ## Rule Details
6 |
7 | Example of **incorrect** code for this rule:
8 |
9 | ```javascript
10 | await page.click('button')
11 | await page.pause()
12 | ```
13 |
14 | Example of **correct** code for this rule:
15 |
16 | ```javascript
17 | await page.click('button')
18 | ```
19 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-useless-await.md:
--------------------------------------------------------------------------------
1 | # Disallow unnecessary `await`s for Playwright methods (`no-useless-await`)
2 |
3 | Some Playwright methods are frequently, yet incorrectly, awaited when the await
4 | expression has no effect.
5 |
6 | ## Rule Details
7 |
8 | Examples of **incorrect** code for this rule:
9 |
10 | ```javascript
11 | await page.locator('.my-element')
12 | await page.getByRole('.my-element')
13 | ```
14 |
15 | Examples of **correct** code for this rule:
16 |
17 | ```javascript
18 | page.locator('.my-element')
19 | page.getByRole('.my-element')
20 |
21 | await page.$('.my-element')
22 | await page.goto('.my-element')
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-useless-not.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of `not` matchers when a specific matcher exists (`no-useless-not`)
2 |
3 | Several Playwright matchers are complimentary such as `toBeVisible`/`toBeHidden`
4 | and `toBeEnabled`/`toBeDisabled`. While the `not` variants of each of these
5 | matchers can be used, it's preferred to use the complimentary matcher instead.
6 |
7 | ## Rule Details
8 |
9 | Examples of **incorrect** code for this rule:
10 |
11 | ```javascript
12 | expect(locator).not.toBeVisible()
13 | expect(locator).not.toBeHidden()
14 | expect(locator).not.toBeEnabled()
15 | expect(locator).not.toBeDisabled()
16 | ```
17 |
18 | Example of **correct** code for this rule:
19 |
20 | ```javascript
21 | expect(locator).toBeHidden()
22 | expect(locator).toBeVisible()
23 | expect(locator).toBeDisabled()
24 | expect(locator).toBeEnabled()
25 | ```
26 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-wait-for-selector.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of `page.waitForSelector` (`no-wait-for-selector`)
2 |
3 | ## Rule Details
4 |
5 | Example of **incorrect** code for this rule:
6 |
7 | ```javascript
8 | await page.waitForSelector('#foo')
9 | ```
10 |
11 | Examples of **correct** code for this rule:
12 |
13 | ```javascript
14 | await page.waitForLoadState()
15 | await page.waitForURL('/home')
16 | await page.waitForFunction(() => window.innerWidth < 100)
17 | ```
18 |
--------------------------------------------------------------------------------
/docs/description/playwright_no-wait-for-timeout.md:
--------------------------------------------------------------------------------
1 | # Disallow usage of `page.waitForTimeout` (`no-wait-for-timeout`)
2 |
3 | ## Rule Details
4 |
5 | Example of **incorrect** code for this rule:
6 |
7 | ```javascript
8 | await page.waitForTimeout(5000)
9 | ```
10 |
11 | Examples of **correct** code for this rule:
12 |
13 | ```javascript
14 | // Use signals such as network events, selectors becoming visible and others instead.
15 | await page.waitForLoadState()
16 |
17 | await page.waitForURL('/home')
18 |
19 | await page.waitForFunction(() => window.innerWidth < 100)
20 | ```
21 |
--------------------------------------------------------------------------------
/docs/description/playwright_prefer-strict-equal.md:
--------------------------------------------------------------------------------
1 | # Suggest using `toStrictEqual()` (`prefer-strict-equal`)
2 |
3 | `toStrictEqual` not only checks that two objects contain the same data but also
4 | that they have the same structure. It is common to expect objects to not only
5 | have identical values but also to have identical keys. A stricter equality will
6 | catch cases where two objects do not have identical keys.
7 |
8 | ## Rule details
9 |
10 | This rule triggers a warning if `toEqual()` is used to assert equality.
11 |
12 | ### Default configuration
13 |
14 | The following pattern is considered warning:
15 |
16 | ```javascript
17 | expect({ a: 'a', b: undefined }).toEqual({ a: 'a' }) // true
18 | ```
19 |
20 | The following pattern is not warning:
21 |
22 | ```javascript
23 | expect({ a: 'a', b: undefined }).toStrictEqual({ a: 'a' }) // false
24 | ```
25 |
--------------------------------------------------------------------------------
/docs/description/playwright_prefer-to-contain.md:
--------------------------------------------------------------------------------
1 | # Suggest using `toContain()` (`prefer-to-contain`)
2 |
3 | In order to have a better failure message, `toContain()` should be used upon
4 | asserting expectations on an array containing an object.
5 |
6 | ## Rule Details
7 |
8 | Example of **incorrect** code for this rule:
9 |
10 | ```javascript
11 | expect(a.includes(b)).toBe(true)
12 | expect(a.includes(b)).not.toBe(true)
13 | expect(a.includes(b)).toBe(false)
14 | expect(a.includes(b)).toEqual(true)
15 | expect(a.includes(b)).toStrictEqual(true)
16 | ```
17 |
18 | Example of **correct** code for this rule:
19 |
20 | ```javascript
21 | expect(a).toContain(b)
22 | expect(a).not.toContain(b)
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/playwright_prefer-to-have-count.md:
--------------------------------------------------------------------------------
1 | # Suggest using `toHaveCount()` (`prefer-to-have-count`)
2 |
3 | In order to have a better failure message, `toHaveCount()` should be used upon
4 | asserting expectations on locators `count()` method.
5 |
6 | ## Rule details
7 |
8 | This rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is
9 | used to assert locators `count()` method.
10 |
11 | The following patterns are considered warnings:
12 |
13 | ```javascript
14 | expect(await files.count()).toBe(1)
15 | expect(await files.count()).toEqual(1)
16 | expect(await files.count()).toStrictEqual(1)
17 | ```
18 |
19 | The following pattern is **not** a warning:
20 |
21 | ```javascript
22 | await expect(files).toHaveCount(1)
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/playwright_prefer-to-have-length.md:
--------------------------------------------------------------------------------
1 | # Suggest using `toHaveLength()` (`prefer-to-have-length`)
2 |
3 | In order to have a better failure message, `toHaveLength()` should be used upon
4 | asserting expectations on objects length property.
5 |
6 | ## Rule details
7 |
8 | This rule triggers a warning if `toBe()`, `toEqual()` or `toStrictEqual()` is
9 | used to assert objects length property.
10 |
11 | The following patterns are considered warnings:
12 |
13 | ```javascript
14 | expect(files.length).toBe(1)
15 | expect(files.length).toEqual(1)
16 | expect(files.length).toStrictEqual(1)
17 | ```
18 |
19 | The following pattern is **not** a warning:
20 |
21 | ```javascript
22 | expect(files).toHaveLength(1)
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/promise_avoid-new.md:
--------------------------------------------------------------------------------
1 | # Avoid creating `new` promises outside of utility libs (use [pify][] instead) (avoid-new)
2 |
3 | [pify]: https://www.npmjs.com/package/pify
4 |
--------------------------------------------------------------------------------
/docs/description/promise_no-multiple-resolved.md:
--------------------------------------------------------------------------------
1 | # Disallow creating new promises with paths that resolve multiple times (no-multiple-resolved)
2 |
3 | This rule warns of paths that resolve multiple times in executor functions that
4 | Promise constructors.
5 |
6 | #### Valid
7 |
8 | ```js
9 | new Promise((resolve, reject) => {
10 | fn((error, value) => {
11 | if (error) {
12 | reject(error)
13 | } else {
14 | resolve(value)
15 | }
16 | })
17 | })
18 | ```
19 |
20 | #### Invalid
21 |
22 | ```js
23 | new Promise((resolve, reject) => {
24 | fn((error, value) => {
25 | if (error) {
26 | reject(error)
27 | }
28 |
29 | resolve(value) // Both `reject` and `resolve` may be called.
30 | })
31 | })
32 | ```
33 |
--------------------------------------------------------------------------------
/docs/description/promise_no-native.md:
--------------------------------------------------------------------------------
1 | # In an ES5 environment, make sure to create a `Promise` constructor before using (no-native)
2 |
3 | Ensure that `Promise` is included fresh in each file instead of relying on the
4 | existence of a native promise implementation. Helpful if you want to use
5 | `bluebird` or if you don't intend to use an ES6 Promise shim.
6 |
7 | #### Valid
8 |
9 | ```js
10 | var Promise = require('bluebird')
11 | var x = Promise.resolve('good')
12 | ```
13 |
14 | #### Invalid
15 |
16 | ```js
17 | var x = Promise.resolve('bad')
18 | ```
19 |
--------------------------------------------------------------------------------
/docs/description/promise_no-nesting.md:
--------------------------------------------------------------------------------
1 | # Avoid nested `then()` or `catch()` statements (no-nesting)
2 |
3 | #### Valid
4 |
5 | ```js
6 | myPromise.then(doSomething).then(doSomethingElse).catch(errors)
7 | ```
8 |
9 | #### Invalid
10 |
11 | ```js
12 | myPromise.then((val) => doSomething(val).then(doSomethingElse))
13 |
14 | myPromise.then((val) => doSomething(val).catch(errors))
15 |
16 | myPromise.catch((err) => doSomething(err).then(doSomethingElse))
17 |
18 | myPromise.catch((err) => doSomething(err).catch(errors))
19 | ```
20 |
--------------------------------------------------------------------------------
/docs/description/promise_no-promise-in-callback.md:
--------------------------------------------------------------------------------
1 | # Avoid using promises inside of callbacks (no-promise-in-callback)
2 |
--------------------------------------------------------------------------------
/docs/description/promise_no-return-in-finally.md:
--------------------------------------------------------------------------------
1 | # Disallow return statements in `finally()` (no-return-in-finally)
2 |
3 | Disallow return statements inside a callback passed to `finally()`, since
4 | nothing would consume what's returned.
5 |
6 | #### Valid
7 |
8 | ```js
9 | myPromise.finally(function (val) {
10 | console.log('value:', val)
11 | })
12 | ```
13 |
14 | #### Invalid
15 |
16 | ```js
17 | myPromise.finally(function (val) {
18 | return val
19 | })
20 | ```
21 |
--------------------------------------------------------------------------------
/docs/description/promise_prefer-await-to-callbacks.md:
--------------------------------------------------------------------------------
1 | # Prefer async/await to the callback pattern (prefer-await-to-callbacks)
2 |
--------------------------------------------------------------------------------
/docs/description/react-native-a11y_has-accessibility-hint.md:
--------------------------------------------------------------------------------
1 | # has-accessibility-hint
2 |
3 | An accessibility hint helps users understand what will happen when they perform an action on the accessibility element when that result is not apparent from the accessibility label.
4 |
5 | ### References
6 |
7 | 1. [React Native Docs - accessibilityHint (iOS, Android)](https://facebook.github.io/react-native/docs/accessibility#accessibilityhint-ios-android)
8 |
9 | ## Rule details
10 |
11 | This rule takes no arguments.
12 |
13 | ### Succeed
14 | ```jsx
15 |
20 | Back
21 |
22 | ```
23 |
24 | ### Fail
25 | ```jsx
26 |
27 | Back
28 |
29 | ```
30 |
--------------------------------------------------------------------------------
/docs/description/react-native_no-raw-text.md:
--------------------------------------------------------------------------------
1 | # Detect raw text outside of Text component
2 | All strings in React Native should be wrapped with a Text component.
3 |
4 | ## Rule Details
5 |
6 | The following patterns are considered warnings:
7 |
8 | ```js
9 | some text
10 | ```
11 |
12 | ```js
13 | const text = 'some text';
14 | {`${text}`}
15 | ```
16 |
17 | The following patterns are not considered warnings:
18 |
19 | ```js
20 | some text {`${text}`} - {}} />
13 |
14 |
(subscriber => {
21 | subscriber.next(42);
22 | subscriber.next(54);
23 | subscriber.complete();
24 | });
25 | ```
26 |
27 | ## Options
28 |
29 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-explicit-generics.md:
--------------------------------------------------------------------------------
1 | # Avoid unnecessary explicit type arguments (`no-explicit-generics`)
2 |
3 | This rule prevents the use of explicit type arguments when the type arguments can be inferred.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { BehaviorSubject } from "rxjs";
11 | const subject = new BehaviorSubject(42);
12 | ```
13 |
14 | Examples of **correct** code for this rule:
15 |
16 | ```ts
17 | import { BehaviorSubject } from "rxjs";
18 | const subject = new BehaviorSubject(42);
19 | ```
20 |
21 | ## Options
22 |
23 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-finnish.md:
--------------------------------------------------------------------------------
1 | # Avoid Finnish notation (`no-finnish`)
2 |
3 | This rule prevents the use of Finnish notation.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | const answer$ = of(42, 54);
11 | ```
12 |
13 | Examples of **correct** code for this rule:
14 |
15 | ```ts
16 | const answers = of(42, 54);
17 | ```
18 |
19 | ## Options
20 |
21 | This rule has no options.
22 |
23 | ## Further reading
24 |
25 | - [Observables and Finnish Notation](https://medium.com/@benlesh/observables-and-finnish-notation-df8356ed1c9b)
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-error.md:
--------------------------------------------------------------------------------
1 | # Enforce the passing of error handlers (`no-ignored-error`)
2 |
3 | This rule enforces the passing of an error handler to `subscribe` calls.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | source.subscribe((value) => console.log(value));
11 | ```
12 |
13 | ```ts
14 | source.subscribe({
15 | next: (value) => console.log(value)
16 | });
17 | ```
18 |
19 | Examples of **correct** code for this rule:
20 |
21 | ```ts
22 | source.subscribe(
23 | (value) => console.log(value),
24 | (error) => console.error(error)
25 | );
26 | ```
27 |
28 | ```ts
29 | source.subscribe({
30 | next: (value) => console.log(value),
31 | error: (error) => console.error(error)
32 | });
33 | ```
34 |
35 | ## Options
36 |
37 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-notifier.md:
--------------------------------------------------------------------------------
1 | # Ensure `repeatWhen` or `retryWhen` notifiers are used (`no-ignored-notifier`)
2 |
3 | This rule effects failures if the notifier passed to a `repeatWhen` or `retryWhen` callback is not used.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { range } from "rxjs";
11 | import { repeatWhen, take } from "rxjs/operators";
12 |
13 | const repeating = source.pipe(
14 | repeatWhen(notifications => range(0, 3))
15 | );
16 | ```
17 |
18 | Examples of **correct** code for this rule:
19 |
20 | ```ts
21 | import { repeatWhen, take } from "rxjs/operators";
22 |
23 | const repeating = source.pipe(
24 | repeatWhen(notifications => notifications.pipe(take(3)))
25 | );
26 | ```
27 |
28 | ## Options
29 |
30 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-observable.md:
--------------------------------------------------------------------------------
1 | # Use returned observables (`no-ignored-observable`)
2 |
3 | The effects failures if an observable returned by a function is neither assigned to a variable or property or passed to a function.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { of } from "rxjs";
11 | of(42, 54);
12 | ```
13 |
14 | Examples of **correct** code for this rule:
15 |
16 | ```ts
17 | import { of } from "rxjs";
18 | const answers = of(42, 54);
19 | ```
20 |
21 | ## Options
22 |
23 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-replay-buffer.md:
--------------------------------------------------------------------------------
1 | # Avoid unbounded replay buffers (`no-ignored-replay-buffer`)
2 |
3 | This rule effects failures if the buffer size of a replay buffer is not explicitly specified.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { ReplaySubject } from "rxjs";
11 | const subject = new ReplaySubject();
12 | ```
13 |
14 | Examples of **correct** code for this rule:
15 |
16 | ```ts
17 | import { ReplaySubject } from "rxjs";
18 | const subject = new ReplaySubject(1);
19 | ```
20 |
21 | ```ts
22 | import { ReplaySubject } from "rxjs";
23 | const subject = new ReplaySubject(Infinity);
24 | ```
25 |
26 | ## Options
27 |
28 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-subscribe.md:
--------------------------------------------------------------------------------
1 | # Enforce the passing of handlers to `subscribe` (`no-ignored-subscribe`)
2 |
3 | This rule effects failures whenever `subscribe` is called without handlers.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { of } from "rxjs";
11 | import { tap } from "rxjs/operators";
12 |
13 | of(42, 54).pipe(
14 | tap((value) => console.log(value))
15 | ).subscribe();
16 | ```
17 |
18 | Examples of **correct** code for this rule:
19 |
20 | ```ts
21 | import { of } from "rxjs";
22 |
23 | of(42, 54).subscribe((value) => console.log(value));
24 | ```
25 |
26 | ## Options
27 |
28 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-ignored-takewhile-value.md:
--------------------------------------------------------------------------------
1 | # Avoid unused `takeWhile` values (`no-ignored-takewhile-value`)
2 |
3 | This rule effects failures if the value received by a `takeWhile` callback is not used in an expression.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { takeWhile } from "rxjs/operators";
11 |
12 | let flag = true;
13 | const whilst = source.pipe(takeWhile(() => flag));
14 | ```
15 |
16 | Examples of **correct** code for this rule:
17 |
18 | ```ts
19 | import { takeWhile } from "rxjs/operators";
20 |
21 | const whilst = source.pipe(takeWhile(value => value));
22 | ```
23 |
24 | ## Options
25 |
26 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-index.md:
--------------------------------------------------------------------------------
1 | # Avoid importing index modules (`no-index`)
2 |
3 | This rule effects failures if an index module is specified as the import location.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { of } from "rxjs/index";
11 | ```
12 |
13 | Examples of **correct** code for this rule:
14 |
15 | ```ts
16 | import { of } from "rxjs";
17 | ```
18 |
19 | ## Options
20 |
21 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-internal.md:
--------------------------------------------------------------------------------
1 | # Avoid importing internal modules (`no-internal`)
2 |
3 | This rule effects failures if an internal module is specified as the import location.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { of } from "rxjs/internal/observable/of";
11 | ```
12 |
13 | Examples of **correct** code for this rule:
14 |
15 | ```ts
16 | import { of } from "rxjs";
17 | ```
18 |
19 | ## Options
20 |
21 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-nested-subscribe.md:
--------------------------------------------------------------------------------
1 | # Avoid nested `subscribe` calls (`no-nested-subscribe`)
2 |
3 | This rule effects failures if `subscribe` is called within a `subscribe` handler.
4 |
5 | ## Rule details
6 |
7 | Examples of **incorrect** code for this rule:
8 |
9 | ```ts
10 | import { of, timer } from "rxjs";
11 |
12 | of(42, 54).subscribe((value) => {
13 | timer(1e3).subscribe(() => console.log(value));
14 | });
15 | ```
16 |
17 | Examples of **correct** code for this rule:
18 |
19 | ```ts
20 | import { of, timer } from "rxjs";
21 | import { mapTo, mergeMap } from "rxjs/operators";
22 |
23 | of(42, 54).pipe(
24 | mergeMap((value) => timer(1e3).pipe(mapTo(value)))
25 | ).subscribe((value) => console.log(value));
26 | ```
27 |
28 | ## Options
29 |
30 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-sharereplay.md:
--------------------------------------------------------------------------------
1 | # Avoid `shareReplay` (`no-sharereplay`)
2 |
3 | This rule effects failures if the `shareReplay` operator is used - or if it is used without specifying a `config` argument.
4 |
5 | The behaviour of `shareReplay` has changed several times - see the blog post linked below.
6 |
7 | ## Options
8 |
9 | This rule accepts a single option which is an object with an `allowConfig` property that that determines whether `shareReplay` is allow if a config argument is specified. By default, `allowConfig` is `true`.
10 |
11 | ```json
12 | {
13 | "rxjs/no-sharereplay": [
14 | "error",
15 | { "allowConfig": true }
16 | ]
17 | }
18 | ```
19 |
20 | ## Further reading
21 |
22 | - [What's changed with shareReplay](https://ncjamieson.com/whats-changed-with-sharereplay/)
--------------------------------------------------------------------------------
/docs/description/rxjs_no-subclass.md:
--------------------------------------------------------------------------------
1 | # Avoid subclassing RxJS classes (`no-subclass`)
2 |
3 | This rule effects failures if an RxJS class is subclassed. Developers are encouraged to avoid subclassing RxJS classes, as some public and protected implementation details might change in the future.
4 |
5 | ## Options
6 |
7 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-subject-unsubscribe.md:
--------------------------------------------------------------------------------
1 | # Avoid calling `unsubscribe` on subjects (`no-subject-unsubscribe`)
2 |
3 | This rule effects failures if the `unsubscribe` method is called on subjects. The method behaves differently to the `unsubsribe` method on subscriptions and is often an error.
4 |
5 | ## Options
6 |
7 | This rule has no options.
8 |
9 | ## Further reading
10 |
11 | - [Closed Subjects](https://ncjamieson.com/closed-subjects/)
--------------------------------------------------------------------------------
/docs/description/rxjs_no-subject-value.md:
--------------------------------------------------------------------------------
1 | # Avoid using a behavior subject's value (`no-subject-value`)
2 |
3 | This rule effects an error if the `value` property - or `getValue` method - of a `BehaviorSubject` is used.
4 |
5 | ## Options
6 |
7 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-tap.md:
--------------------------------------------------------------------------------
1 | # Avoid `tap` (`no-tap`)
2 |
3 | This rule effects failures if the `tap` operator is used.
4 |
5 | ## Options
6 |
7 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-topromise.md:
--------------------------------------------------------------------------------
1 | # Avoid `toPromise` (`no-topromise`)
2 |
3 | This rule effects failures if the `toPromise` method is used.
4 |
5 | ## Options
6 |
7 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/rxjs_no-unsafe-first.md:
--------------------------------------------------------------------------------
1 | # Avoid completing effects and epics (`no-unsafe-first`)
2 |
3 | This rule effects failures if `first` is used in an effect or epic in a manner that will complete the outermost observable.
4 |
5 | ## Options
6 |
7 | This rule accepts a single option which is an object with an `observable` property that is a regular expression used to match an effect or epic's actions observable. The default `observable` regular expression should match most effect and epic action sources.
8 |
9 | ```json
10 | {
11 | "rxjs/no-unsafe-first": [
12 | "error",
13 | { "observable": "[Aa]ction(s|s\\$|\\$)$" }
14 | ]
15 | }
16 | ```
--------------------------------------------------------------------------------
/docs/description/rxjs_no-unsafe-subject-next.md:
--------------------------------------------------------------------------------
1 | # Avoid passing `undefined` to `next` (`no-unsafe-subject-next`)
2 |
3 | This rule effects failures if `next` is called without an argument and the subject's value type is not `void`.
4 |
5 | In RxJS version 6, the `next` method's `value` parameter is optional, but a value should always be specified for subjects with non-`void` element types.
6 |
7 | ## Rule details
8 |
9 | Examples of **incorrect** code for this rule:
10 |
11 | ```ts
12 | const subject = new Subject();
13 | subject.next();
14 | ```
15 |
16 | Examples of **correct** code for this rule:
17 |
18 | ```ts
19 | const subject = new Subject();
20 | subject.next();
21 | ```
22 |
23 | ```ts
24 | const subject = new Subject();
25 | subject.next(0);
26 | ```
27 |
28 | ## Options
29 |
30 | This rule has no options.
--------------------------------------------------------------------------------
/docs/description/security-node_detect-possible-timing-attacks.md:
--------------------------------------------------------------------------------
1 | # detect possible timing attacks (detect-possible-timing-attacks)
2 |
3 | Please describe the origin of the rule here.
4 |
5 |
6 | ## Rule Details
7 |
8 | This rule aims to...
9 |
10 | Examples of **incorrect** code for this rule:
11 |
12 | ```js
13 |
14 | // fill me in
15 |
16 | ```
17 |
18 | Examples of **correct** code for this rule:
19 |
20 | ```js
21 |
22 | // fill me in
23 |
24 | ```
25 |
26 | ### Options
27 |
28 | If there are any options, describe them here. Otherwise, delete this section.
29 |
30 | ## When Not To Use It
31 |
32 | Give a short description of when it would be appropriate to turn off this rule.
33 |
34 | ## Further Reading
35 |
36 | If there are other links that describe the issue this rule addresses, please include them here in a bulleted list.
37 |
--------------------------------------------------------------------------------
/docs/description/security_detect-buffer-noassert.md:
--------------------------------------------------------------------------------
1 | # Detects calls to "buffer" with "noAssert" flag set (`security/detect-buffer-noassert`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | Detect calls to [`buffer`](https://nodejs.org/api/buffer.html) with `noAssert` flag set.
8 |
9 | From the Node.js API docs: "Setting `noAssert` to true skips validation of the `offset`. This allows the `offset` to be beyond the end of the `Buffer`."
10 |
--------------------------------------------------------------------------------
/docs/description/security_detect-child-process.md:
--------------------------------------------------------------------------------
1 | # Detects instances of "child_process" & non-literal "exec()" calls (`security/detect-child-process`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | Detect instances of [`child_process`](https://nodejs.org/api/child_process.html) & non-literal [`exec()`](https://nodejs.org/api/child_process.html#child_process_child_process_exec_command_options_callback)
8 |
9 | More information: [Avoiding Command Injection in Node.js](https://github.com/eslint-community/eslint-plugin-security/tree/main/docs/avoid-command-injection-node.md)
10 |
--------------------------------------------------------------------------------
/docs/description/security_detect-disable-mustache-escape.md:
--------------------------------------------------------------------------------
1 | # Detects "object.escapeMarkup = false", which can be used with some template engines to disable escaping of HTML entities (`security/detect-disable-mustache-escape`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | This can lead to Cross-Site Scripting (XSS) vulnerabilities.
8 |
9 | More information: [OWASP XSS]()
10 |
--------------------------------------------------------------------------------
/docs/description/security_detect-eval-with-expression.md:
--------------------------------------------------------------------------------
1 | # Detects "eval(variable)" which can allow an attacker to run arbitrary code inside your process (`security/detect-eval-with-expression`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | More information: [What are the security issues with eval in JavaScript?](http://security.stackexchange.com/questions/94017/what-are-the-security-issues-with-eval-in-javascript)
8 |
--------------------------------------------------------------------------------
/docs/description/security_detect-new-buffer.md:
--------------------------------------------------------------------------------
1 | # Detects instances of new Buffer(argument) where argument is any non-literal value (`security/detect-new-buffer`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | `new Buffer()` now emits a deprecation warning in Node.js.
8 |
9 | More information: [new Buffer(number) is unsafe](https://github.com/nodejs/node/issues/4660)
10 |
--------------------------------------------------------------------------------
/docs/description/security_detect-no-csrf-before-method-override.md:
--------------------------------------------------------------------------------
1 | # Detects Express "csrf" middleware setup before "method-override" middleware (`security/detect-no-csrf-before-method-override`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | This can allow `GET` requests (which are not checked by `csrf`) to turn into `POST` requests later.
8 |
9 | More information: [Bypass Connect CSRF protection by abusing methodOverride Middleware](https://github.com/eslint-community/eslint-plugin-security/tree/main/docs/bypass-connect-csrf-protection-by-abusing.md)
10 |
--------------------------------------------------------------------------------
/docs/description/security_detect-non-literal-fs-filename.md:
--------------------------------------------------------------------------------
1 | # Detects variable in filename argument of "fs" calls, which might allow an attacker to access anything on your system (`security/detect-non-literal-fs-filename`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | More information: [OWASP Path Traversal](https://www.owasp.org/index.php/Path_Traversal)
8 |
--------------------------------------------------------------------------------
/docs/description/security_detect-non-literal-regexp.md:
--------------------------------------------------------------------------------
1 | # Detects "RegExp(variable)", which might allow an attacker to DOS your server with a long-running regular expression (`security/detect-non-literal-regexp`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | More information: [Regular Expression DoS and Node.js](https://github.com/eslint-community/eslint-plugin-security/tree/main/docs/regular-expression-dos-and-node.md)
8 |
--------------------------------------------------------------------------------
/docs/description/security_detect-non-literal-require.md:
--------------------------------------------------------------------------------
1 | # Detects "require(variable)", which might allow an attacker to load and run arbitrary code, or access arbitrary files on disk (`security/detect-non-literal-require`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | More information: [Where does Node.js and require look for modules?](http://www.bennadel.com/blog/2169-where-does-node-js-and-require-look-for-modules.htm)
8 |
--------------------------------------------------------------------------------
/docs/description/security_detect-possible-timing-attacks.md:
--------------------------------------------------------------------------------
1 | # Detects insecure comparisons (`==`, `!=`, `!==` and `===`), which check input sequentially (`security/detect-possible-timing-attacks`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
--------------------------------------------------------------------------------
/docs/description/security_detect-pseudoRandomBytes.md:
--------------------------------------------------------------------------------
1 | # Detects if "pseudoRandomBytes()" is in use, which might not give you the randomness you need and expect (`security/detect-pseudoRandomBytes`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
--------------------------------------------------------------------------------
/docs/description/security_detect-unsafe-regex.md:
--------------------------------------------------------------------------------
1 | # Detects potentially unsafe regular expressions, which may take a very long time to run, blocking the event loop (`security/detect-unsafe-regex`)
2 |
3 | ⚠️ This rule _warns_ in the ✅ `recommended` config.
4 |
5 |
6 |
7 | More information: [Regular Expression DoS and Node.js](https://github.com/eslint-community/eslint-plugin-security/tree/main/docs/regular-expression-dos-and-node.md)
8 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_cognitive-complexity.md:
--------------------------------------------------------------------------------
1 | # cognitive-complexity
2 |
3 | Cognitive Complexity is a measure of how hard the control flow of a function is to understand. Functions with high Cognitive Complexity will be difficult to maintain.
4 |
5 | ## See
6 |
7 | - [Cognitive Complexity](https://www.sonarsource.com/resources/cognitive-complexity/)
8 |
9 | ## Configuration
10 |
11 | The maximum authorized complexity can be provided. Default is 15.
12 |
13 | ```json
14 | {
15 | "sonarjs/cognitive-complexity": "error",
16 | "sonarjs/cognitive-complexity": ["error", 15]
17 | }
18 | ```
19 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_max-switch-cases.md:
--------------------------------------------------------------------------------
1 | ## max-switch-cases
2 |
3 | When `switch` statements have large sets of `case` clauses, it is usually an attempt to map two sets of data. A real map structure would be more readable and maintainable, and should be used instead.
4 |
5 | ## Configuration
6 |
7 | This rule has a numeric option (defaulted to 30) to specify the maximum number of switch cases.
8 |
9 | ```json
10 | {
11 | "max-switch-cases": "error",
12 | "max-switch-cases": ["error", 10]
13 | }
14 | ```
15 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-collapsible-if.md:
--------------------------------------------------------------------------------
1 | # no-collapsible-if
2 |
3 | Merging collapsible if statements increases the code's readability.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | if (x != undefined) {
9 | if (y === 2) {
10 | // ...
11 | }
12 | }
13 | ```
14 |
15 | ## Compliant Solution
16 |
17 | ```javascript
18 | if (x != undefined && y === 2) {
19 | // ...
20 | }
21 | ```
22 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-element-overwrite.md:
--------------------------------------------------------------------------------
1 | # no-element-overwrite
2 |
3 | It is highly suspicious when a value is saved for a key or index and then unconditionally overwritten. Such replacements are likely in error.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | fruits[1] = 'banana';
9 | fruits[1] = 'apple'; // Noncompliant - value on index 1 is overwritten
10 |
11 | myMap.set('key', 1);
12 | myMap.set('key', 2); // Noncompliant - value for key "key" is replaced
13 |
14 | mySet.add(1);
15 | mySet.add(1); // Noncompliant - element is already in the set
16 | ```
17 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-empty-collection.md:
--------------------------------------------------------------------------------
1 | # no-empty-collection
2 |
3 | When a collection is empty it makes no sense to access or iterate it. Doing so anyway is surely an error; either population was accidentally omitted or the developer doesn’t understand the situation.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | let strings = [];
9 |
10 | if (strings.includes('foo')) {} // Noncompliant
11 |
12 | for (str of strings) {} // Noncompliant
13 |
14 | strings.forEach(str => doSomething(str)); // Noncompliant
15 | ```
16 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-extra-arguments.md:
--------------------------------------------------------------------------------
1 | # no-extra-arguments
2 |
3 | You can easily call a JavaScript function with more arguments than the function needs, but the extra arguments will be just ignored by function execution.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | function say(a, b) {
9 | print(a + ' ' + b);
10 | }
11 |
12 | say('hello', 'world', '!'); // Noncompliant; last argument is not used
13 | ```
14 |
15 | ## Exceptions
16 |
17 | No issue is reported when `arguments` is used in the body of the function being called.
18 |
19 | ```javascript
20 | function doSomething(a, b) {
21 | compute(arguments);
22 | }
23 |
24 | doSomething(1, 2, 3); // Compliant
25 | ```
26 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-inverted-boolean-check.md:
--------------------------------------------------------------------------------
1 | # no-inverted-boolean-check
2 |
3 | :wrench: _fixable_
4 |
5 | It is needlessly complex to invert the result of a boolean comparison. The opposite comparison should be made instead.
6 |
7 | ## Noncompliant Code Example
8 |
9 | ```javascript
10 | if (!(a === 2)) { // Noncompliant
11 | //...
12 | }
13 | ```
14 |
15 | ## Compliant Solution
16 |
17 | ```javascript
18 | if (a !== 2) {
19 | //...
20 | }
21 | ```
22 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-redundant-boolean.md:
--------------------------------------------------------------------------------
1 | # no-redundant-boolean
2 |
3 | Redundant Boolean literals should be removed from expressions to improve readability.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | if (booleanMethod() == true) { /* ... */ }
9 | if (booleanMethod() == false) { /* ... */ }
10 | if (booleanMethod() || false) { /* ... */ }
11 | doSomething(!false);
12 | doSomething(booleanMethod() == true);
13 | ```
14 |
15 | ## Compliant Solution
16 |
17 | ```javascript
18 | if (booleanMethod()) { /* ... */ }
19 | if (!booleanMethod()) { /* ... */ }
20 | if (booleanMethod()) { /* ... */ }
21 | doSomething(true);
22 | doSomething(booleanMethod());
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-unused-collection.md:
--------------------------------------------------------------------------------
1 | # no-unused-collection
2 |
3 | When a collection is populated but its contents are never used, then it is surely some kind of mistake. Either refactoring has rendered the collection moot, or an access is missing.
4 |
5 | This rule raises an issue when no methods are called on a collection other than those that add or remove values.
6 |
7 | ## Noncompliant Code Example
8 |
9 | ```javascript
10 | function getLength(a, b, c) {
11 | const strings = []; // Noncompliant
12 | strings.push(a);
13 | strings.push(b);
14 | strings.push(c);
15 |
16 | return a.length + b.length + c.length;
17 | }
18 | ```
19 |
20 | ## Compliant Solution
21 |
22 | ```javascript
23 | function getLength(a, b, c) {
24 | return a.length + b.length + c.length;
25 | }
26 | ```
27 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-use-of-empty-return-value.md:
--------------------------------------------------------------------------------
1 | # no-use-of-empty-return-value
2 |
3 | If a function does not return anything, it makes no sense to use its output. Specifically, passing it to another function, or assigning its "result" to a variable is probably a bug because such functions return `undefined`, which is probably not what was intended.
4 |
5 | ## Noncompliant Code Example
6 |
7 | ```javascript
8 | function foo() {
9 | console.log('Hello, World!');
10 | }
11 |
12 | a = foo();
13 | ```
14 |
15 | ## Compliant Solution
16 |
17 | ```javascript
18 | function foo() {
19 | console.log('Hello, World!');
20 | }
21 |
22 | foo();
23 | ```
24 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_no-useless-catch.md:
--------------------------------------------------------------------------------
1 | # no-useless-catch
2 |
3 | A catch clause that only rethrows the caught exception has the same effect as omitting the catch altogether and letting it bubble up automatically, but with more code and the additional detriment of leaving maintainers scratching their heads.
4 |
5 | Such clauses should either be eliminated or populated with the appropriate logic.
6 |
7 | ## Noncompliant Code Example
8 |
9 | ```javascript
10 | try {
11 | doSomething();
12 | } catch (ex) { // Noncompliant
13 | throw ex;
14 | }
15 | ```
16 |
17 | ## Compliant Solution
18 |
19 | ```javascript
20 | try {
21 | doSomething();
22 | } catch (ex) {
23 | console.err(ex);
24 | throw ex;
25 | }
26 | ```
27 |
28 | or
29 |
30 | ```javascript
31 | doSomething();
32 | ```
33 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_prefer-object-literal.md:
--------------------------------------------------------------------------------
1 | # prefer-object-literal
2 |
3 | Object literal syntax, which initializes an object's properties inside the object declaration is cleaner and clearer than the alternative: creating an empty object, and then giving it properties one by one.
4 |
5 | An issue is raised when the following pattern is met:
6 |
7 | - An empty object is created.
8 | - A consecutive single-line statement adds a property to the created object.
9 |
10 | ## Noncompliant Code Example
11 |
12 | ```javascript
13 | var person = {}; // Noncompliant
14 | person.firstName = 'John';
15 | person.middleInitial = 'Q';
16 | person.lastName = 'Public';
17 | ```
18 |
19 | ## Compliant Solution
20 |
21 | ```javascript
22 | var person = {
23 | firstName: 'John',
24 | middleInitial: 'Q',
25 | lastName: 'Public',
26 | };
27 | ```
28 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_prefer-single-boolean-return.md:
--------------------------------------------------------------------------------
1 | # prefer-single-boolean-return
2 |
3 | :wrench: _fixable_
4 |
5 | Return of boolean literal statements wrapped into `if-then-else` flow should be simplified.
6 |
7 | ## Noncompliant Code Example
8 |
9 | ```javascript
10 | if (expression) {
11 | return true;
12 | } else {
13 | return false;
14 | }
15 | ```
16 |
17 | or
18 |
19 | ```javascript
20 | if (expression) {
21 | return true;
22 | }
23 | return false;
24 | ```
25 |
26 | ## Compliant Solution
27 |
28 | ```javascript
29 | return expression;
30 | ```
31 |
--------------------------------------------------------------------------------
/docs/description/sonarjs_prefer-while.md:
--------------------------------------------------------------------------------
1 | # prefer-while
2 |
3 | :wrench: _fixable_
4 |
5 | When only the condition expression is defined in a `for` loop, and the initialization and increment expressions are missing, a `while` loop should be used instead to increase readability.
6 |
7 | ## Noncompliant Code Example
8 |
9 | ```javascript
10 | for (;condition;) { /*...*/ }
11 | ```
12 |
13 | ## Compliant Solution
14 |
15 | ```javascript
16 | while (condition) { /*...*/ }
17 | ```
18 |
--------------------------------------------------------------------------------
/docs/description/sort-destructure-keys_sort-destructure-keys.md:
--------------------------------------------------------------------------------
1 | # require object destructure keys to be sorted (sort-destructure-keys)
2 |
3 | Keys in an object pattern should be sorted in alphabetical order. The exception
4 | being when any of those keys have a default value equal to previously
5 | destructured key.
6 |
7 | ## Rule Details
8 |
9 | Examples of **incorrect** code for this rule:
10 |
11 | ```js
12 | const {b, a} = someObj;
13 | ```
14 |
15 | Examples of **correct** code for this rule:
16 |
17 | ```js
18 | const {a, b} = someObj;
19 |
20 | const {b, a = b} = someObj;
21 | ```
22 |
--------------------------------------------------------------------------------
/docs/description/test-selectors_anchor.md:
--------------------------------------------------------------------------------
1 | # Requires the `data-test-id` attribute on elements.
2 |
3 | ## Rule Details
4 |
5 | Examples of **incorrect** code for this rule:
6 |
7 | ```html
8 | Download
9 | ```
10 |
11 | Examples of **correct** code for this rule:
12 |
13 | ```html
14 | Download
15 | ```
16 |
17 |
--------------------------------------------------------------------------------
/docs/description/test-selectors_button.md:
--------------------------------------------------------------------------------
1 | # Requires the `data-test-id` attribute on