eslint-plugin-rxjs-x 0.6.1 → 0.6.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +2 -1
- package/dist/index.js +2 -2
- package/dist/index.mjs +2 -2
- package/docs/rules/ban-observables.md +20 -2
- package/docs/rules/ban-operators.md +20 -1
- package/docs/rules/finnish.md +18 -0
- package/docs/rules/just.md +9 -0
- package/docs/rules/no-async-subscribe.md +12 -0
- package/docs/rules/no-connectable.md +27 -1
- package/docs/rules/no-create.md +12 -0
- package/docs/rules/no-cyclic-action.md +14 -0
- package/docs/rules/no-explicit-generics.md +8 -1
- package/docs/rules/no-exposed-subjects.md +18 -3
- package/docs/rules/no-finnish.md +17 -0
- package/docs/rules/no-floating-observables.md +21 -1
- package/docs/rules/no-ignored-default-value.md +12 -0
- package/docs/rules/no-ignored-error.md +14 -0
- package/docs/rules/no-ignored-notifier.md +15 -0
- package/docs/rules/no-ignored-replay-buffer.md +9 -0
- package/docs/rules/no-ignored-subscribe.md +18 -0
- package/docs/rules/no-ignored-subscription.md +13 -0
- package/docs/rules/no-ignored-takewhile-value.md +9 -0
- package/docs/rules/no-implicit-any-catch.md +16 -1
- package/docs/rules/no-index.md +13 -0
- package/docs/rules/no-internal.md +15 -0
- package/docs/rules/no-misused-observables.md +16 -0
- package/docs/rules/no-nested-subscribe.md +14 -0
- package/docs/rules/no-redundant-notify.md +17 -1
- package/docs/rules/no-sharereplay.md +15 -0
- package/docs/rules/no-subclass.md +14 -0
- package/docs/rules/no-subject-unsubscribe.md +51 -1
- package/docs/rules/no-subject-value.md +12 -0
- package/docs/rules/no-subscribe-handlers.md +16 -0
- package/docs/rules/no-subscribe-in-pipe.md +19 -1
- package/docs/rules/no-topromise.md +17 -0
- package/docs/rules/no-unbound-methods.md +15 -0
- package/docs/rules/no-unsafe-catch.md +12 -0
- package/docs/rules/no-unsafe-first.md +12 -0
- package/docs/rules/no-unsafe-subject-next.md +15 -1
- package/docs/rules/no-unsafe-switchmap.md +12 -0
- package/docs/rules/no-unsafe-takeuntil.md +11 -0
- package/docs/rules/prefer-observer.md +12 -0
- package/docs/rules/prefer-root-operators.md +11 -0
- package/docs/rules/suffix-subjects.md +24 -1
- package/docs/rules/throw-error.md +13 -0
- package/package.json +15 -15
package/LICENSE
CHANGED
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
MIT License
|
|
2
2
|
|
|
3
|
-
Copyright (c) 2019 Nicholas Jamieson and contributors
|
|
3
|
+
Copyright (c) 2019 Nicholas Jamieson and contributors
|
|
4
|
+
Copyright (c) 2024-2025 Jason Weinzierl and contributors
|
|
4
5
|
|
|
5
6
|
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
7
|
of this software and associated documentation files (the "Software"), to deal
|
package/dist/index.js
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
"use strict";Object.defineProperty(exports, "__esModule", {value: true}); function _interopRequireWildcard(obj) { if (obj && obj.__esModule) { return obj; } else { var newObj = {}; if (obj != null) { for (var key in obj) { if (Object.prototype.hasOwnProperty.call(obj, key)) { newObj[key] = obj[key]; } } } newObj.default = obj; return newObj; } } function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }// package.json
|
|
2
2
|
var name = "eslint-plugin-rxjs-x";
|
|
3
|
-
var version = "0.6.
|
|
3
|
+
var version = "0.6.2";
|
|
4
4
|
|
|
5
5
|
// src/configs/recommended.ts
|
|
6
6
|
var createRecommendedConfig = (plugin2) => ({
|
|
@@ -2560,7 +2560,7 @@ var noRedundantNotifyRule = ruleCreator({
|
|
|
2560
2560
|
const sourceCode = context.sourceCode;
|
|
2561
2561
|
const { couldBeType: couldBeType2 } = getTypeServices(context);
|
|
2562
2562
|
return {
|
|
2563
|
-
"ExpressionStatement[expression.callee.property.name=/^(complete|error)$/] + ExpressionStatement[expression.callee.property.name=/^(next|complete|error)$/]": (node) => {
|
|
2563
|
+
"ExpressionStatement[expression.callee.property.name=/^(complete|error|unsubscribe)$/] + ExpressionStatement[expression.callee.property.name=/^(next|complete|error|unsubscribe)$/]": (node) => {
|
|
2564
2564
|
const parent = node.parent;
|
|
2565
2565
|
if (!parent) {
|
|
2566
2566
|
return;
|
package/dist/index.mjs
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
// package.json
|
|
2
2
|
var name = "eslint-plugin-rxjs-x";
|
|
3
|
-
var version = "0.6.
|
|
3
|
+
var version = "0.6.2";
|
|
4
4
|
|
|
5
5
|
// src/configs/recommended.ts
|
|
6
6
|
var createRecommendedConfig = (plugin2) => ({
|
|
@@ -2560,7 +2560,7 @@ var noRedundantNotifyRule = ruleCreator({
|
|
|
2560
2560
|
const sourceCode = context.sourceCode;
|
|
2561
2561
|
const { couldBeType: couldBeType2 } = getTypeServices(context);
|
|
2562
2562
|
return {
|
|
2563
|
-
"ExpressionStatement[expression.callee.property.name=/^(complete|error)$/] + ExpressionStatement[expression.callee.property.name=/^(next|complete|error)$/]": (node) => {
|
|
2563
|
+
"ExpressionStatement[expression.callee.property.name=/^(complete|error|unsubscribe)$/] + ExpressionStatement[expression.callee.property.name=/^(next|complete|error|unsubscribe)$/]": (node) => {
|
|
2564
2564
|
const parent = node.parent;
|
|
2565
2565
|
if (!parent) {
|
|
2566
2566
|
return;
|
|
@@ -2,11 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
<!-- end auto-generated rule header -->
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
It can sometimes be useful to ban specific `rxjs` imports.
|
|
6
|
+
This rule can be configured to ban a list of specific `rxjs` imports developers want to avoid in their project.
|
|
7
|
+
|
|
8
|
+
> [!TIP]
|
|
9
|
+
> `ban-observables` only bans at the _import_ site. (In fact, it can ban anything imported from `rxjs`.)
|
|
10
|
+
> See [`ban-operators`](./ban-operators.md) for banning operators at their _usage_.
|
|
6
11
|
|
|
7
12
|
## Options
|
|
8
13
|
|
|
9
|
-
This rule accepts a single option which is an object the keys of which are the names of
|
|
14
|
+
This rule accepts a single option which is an object the keys of which are the names of anything in `rxjs` and the values are either booleans or strings containing the explanation for the ban.
|
|
10
15
|
|
|
11
16
|
The following configuration bans `partition` and `onErrorResumeNext`:
|
|
12
17
|
|
|
@@ -22,3 +27,16 @@ The following configuration bans `partition` and `onErrorResumeNext`:
|
|
|
22
27
|
]
|
|
23
28
|
}
|
|
24
29
|
```
|
|
30
|
+
|
|
31
|
+
## When Not To Use It
|
|
32
|
+
|
|
33
|
+
If you have no need to ban importing anything from `rxjs`, you don't need this rule.
|
|
34
|
+
|
|
35
|
+
## Related To
|
|
36
|
+
|
|
37
|
+
- [`ban-operators`](./ban-operators.md)
|
|
38
|
+
|
|
39
|
+
## Resources
|
|
40
|
+
|
|
41
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/ban-observables.ts)
|
|
42
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/ban-observables.test.ts)
|
|
@@ -4,7 +4,10 @@
|
|
|
4
4
|
|
|
5
5
|
<!-- end auto-generated rule header -->
|
|
6
6
|
|
|
7
|
-
This rule can be configured so that developers can ban
|
|
7
|
+
This rule can be configured so that developers can ban `rxjs` operators they want to avoid in their project.
|
|
8
|
+
|
|
9
|
+
> [!NOTE]
|
|
10
|
+
> Operators outside of a `pipe` or not directly exported by `rxjs` are ignored.
|
|
8
11
|
|
|
9
12
|
## Options
|
|
10
13
|
|
|
@@ -23,3 +26,19 @@ The following configuration bans `partition` and `onErrorResumeNext`:
|
|
|
23
26
|
}
|
|
24
27
|
]
|
|
25
28
|
}
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## When Not To Use It
|
|
32
|
+
|
|
33
|
+
If you have no need to ban `rxjs` operators, you don't need this rule.
|
|
34
|
+
|
|
35
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
36
|
+
|
|
37
|
+
## Related To
|
|
38
|
+
|
|
39
|
+
- [`ban-observables`](./ban-observables.md)
|
|
40
|
+
|
|
41
|
+
## Resources
|
|
42
|
+
|
|
43
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/ban-operators.ts)
|
|
44
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/ban-operators.test.ts)
|
package/docs/rules/finnish.md
CHANGED
|
@@ -68,6 +68,24 @@ The default (Angular-friendly) configuration looks like this:
|
|
|
68
68
|
|
|
69
69
|
The properties in the options object are themselves optional; they do not all have to be specified.
|
|
70
70
|
|
|
71
|
+
## When Not To Use It
|
|
72
|
+
|
|
73
|
+
If you don't use Finnish notation in your project or don't care about enforcing Finnish notation in your project, you don't need this rule.
|
|
74
|
+
However, keep in mind that inconsistent style can harm readability in a project;
|
|
75
|
+
consider using [`no-finnish`](./no-finnish.md) to ban Finnish notation if you don't use it in your project.
|
|
76
|
+
|
|
77
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
78
|
+
|
|
71
79
|
## Further reading
|
|
72
80
|
|
|
73
81
|
- [Observables and Finnish Notation](https://medium.com/@benlesh/observables-and-finnish-notation-df8356ed1c9b)
|
|
82
|
+
|
|
83
|
+
## Related To
|
|
84
|
+
|
|
85
|
+
- [`no-finnish`](./no-finnish.md)
|
|
86
|
+
- [`suffix-subjects`](./suffix-subjects.md)
|
|
87
|
+
|
|
88
|
+
## Resources
|
|
89
|
+
|
|
90
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/finnish.ts)
|
|
91
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/finnish.test.ts)
|
package/docs/rules/just.md
CHANGED
|
@@ -6,6 +6,15 @@
|
|
|
6
6
|
|
|
7
7
|
This rule enforces the use of `just` instead of `of`. Some other languages with Rx implementations use the former and this rule is for developers who have that preference.
|
|
8
8
|
|
|
9
|
+
## When Not To Use It
|
|
10
|
+
|
|
11
|
+
If you prefer `of` in your project, you will want to avoid this rule.
|
|
12
|
+
|
|
9
13
|
## Further reading
|
|
10
14
|
|
|
11
15
|
- [Rename `of` to `just`](https://github.com/ReactiveX/rxjs/issues/3747)
|
|
16
|
+
|
|
17
|
+
## Resources
|
|
18
|
+
|
|
19
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/just.ts)
|
|
20
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/just.test.ts)
|
|
@@ -36,7 +36,19 @@ of(42).pipe(
|
|
|
36
36
|
).subscribe(data2 => console.log(data2));
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
+
## When Not To Use It
|
|
40
|
+
|
|
41
|
+
If you don't care about avoiding `.subscribe(async...`, then you will not need this rule.
|
|
42
|
+
However, keep in mind that features of observables like cancellation or retrying will not work, and race conditions may occur.
|
|
43
|
+
|
|
44
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
45
|
+
|
|
39
46
|
## Further reading
|
|
40
47
|
|
|
41
48
|
- [Why does this rule exist?](https://stackoverflow.com/q/71559135)
|
|
42
49
|
- [Higher-order Observables](https://rxjs.dev/guide/higher-order-observables)
|
|
50
|
+
|
|
51
|
+
## Resources
|
|
52
|
+
|
|
53
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-async-subscribe.ts)
|
|
54
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-async-subscribe.test.ts)
|
|
@@ -4,4 +4,30 @@
|
|
|
4
4
|
|
|
5
5
|
<!-- end auto-generated rule header -->
|
|
6
6
|
|
|
7
|
-
This rule prevents the use of connectable observables.
|
|
7
|
+
This rule prevents the use of operators that return connectable observables.
|
|
8
|
+
|
|
9
|
+
> [!NOTE]
|
|
10
|
+
> All operators banned by this rule are also deprecated by RxJS,
|
|
11
|
+
> so this rule may be removed in a future major version.
|
|
12
|
+
|
|
13
|
+
## Rule details
|
|
14
|
+
|
|
15
|
+
Examples of **incorrect** code for this rule:
|
|
16
|
+
|
|
17
|
+
```ts
|
|
18
|
+
import { of, publish } from "rxjs";
|
|
19
|
+
|
|
20
|
+
const result = of(42).pipe(publish());
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## When Not To Use It
|
|
24
|
+
|
|
25
|
+
If you use operators that return connectable observables in your project, you may not need this rule.
|
|
26
|
+
Or you may rely on RxJS's deprecation of those operators and don't need to double-flag the operators as banned.
|
|
27
|
+
|
|
28
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
29
|
+
|
|
30
|
+
## Resources
|
|
31
|
+
|
|
32
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-connectable.ts)
|
|
33
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-connectable.test.ts)
|
package/docs/rules/no-create.md
CHANGED
|
@@ -29,3 +29,15 @@ const answers = new Observable<number>(subscriber => {
|
|
|
29
29
|
subscriber.complete();
|
|
30
30
|
});
|
|
31
31
|
```
|
|
32
|
+
|
|
33
|
+
## When Not To Use It
|
|
34
|
+
|
|
35
|
+
If you rely on RxJS's deprecation of `Observable.create` and don't need to double-flag usage,
|
|
36
|
+
then you don't need this rule.
|
|
37
|
+
|
|
38
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
39
|
+
|
|
40
|
+
## Resources
|
|
41
|
+
|
|
42
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-create.ts)
|
|
43
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-create.test.ts)
|
|
@@ -72,3 +72,17 @@ This rule accepts a single option which is an object with an `observable` proper
|
|
|
72
72
|
]
|
|
73
73
|
}
|
|
74
74
|
```
|
|
75
|
+
|
|
76
|
+
## When Not To Use It
|
|
77
|
+
|
|
78
|
+
If you don't use a library with effects and epics (e.g. NgRx or redux-observable),
|
|
79
|
+
then you don't need this rule.
|
|
80
|
+
Alternatively, if you use NgRx's own [`avoid-cyclic-effects`](https://ngrx.io/guide/eslint-plugin/rules/avoid-cyclic-effects) rule,
|
|
81
|
+
then you don't need this rule.
|
|
82
|
+
|
|
83
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
84
|
+
|
|
85
|
+
## Resources
|
|
86
|
+
|
|
87
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-cyclic-action.ts)
|
|
88
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-cyclic-action.test.ts)
|
|
@@ -20,6 +20,13 @@ import { BehaviorSubject } from "rxjs";
|
|
|
20
20
|
const subject = new BehaviorSubject(42);
|
|
21
21
|
```
|
|
22
22
|
|
|
23
|
-
##
|
|
23
|
+
## When Not To Use It
|
|
24
|
+
|
|
25
|
+
This rule has known problems in the latest release:
|
|
24
26
|
|
|
25
27
|
- ([#77](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/issues/77)) Type unions cause false positives e.g. `new BehaviorSubject<number | null>(null)` will be incorrectly caught by this rule.
|
|
28
|
+
|
|
29
|
+
## Resources
|
|
30
|
+
|
|
31
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-explicit-generics.ts)
|
|
32
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-explicit-generics.test.ts)
|
|
@@ -23,10 +23,13 @@ Examples of **correct** code for this rule:
|
|
|
23
23
|
|
|
24
24
|
```ts
|
|
25
25
|
import { Subject } from "rxjs";
|
|
26
|
+
|
|
26
27
|
class Answers {
|
|
27
|
-
private
|
|
28
|
-
|
|
29
|
-
|
|
28
|
+
private answersSubject$ = new Subject<string>();
|
|
29
|
+
public answers$ = this.answersSubject$.asObservable();
|
|
30
|
+
|
|
31
|
+
public nextAnswer(a: string) {
|
|
32
|
+
this.answersSubject$.next(a);
|
|
30
33
|
}
|
|
31
34
|
}
|
|
32
35
|
```
|
|
@@ -51,3 +54,15 @@ This rule accepts a single option which is an object with an `allowProtected` pr
|
|
|
51
54
|
]
|
|
52
55
|
}
|
|
53
56
|
```
|
|
57
|
+
|
|
58
|
+
## When Not To Use It
|
|
59
|
+
|
|
60
|
+
If you don't care about encapsulating subjects in your project, then you don't need this rule.
|
|
61
|
+
However, be aware that anyone can call `next()` or `complete()` on the exposed subject, which may cause bugs or less readable code.
|
|
62
|
+
|
|
63
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
64
|
+
|
|
65
|
+
## Resources
|
|
66
|
+
|
|
67
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-exposed-subjects.ts)
|
|
68
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-exposed-subjects.test.ts)
|
package/docs/rules/no-finnish.md
CHANGED
|
@@ -20,6 +20,23 @@ Examples of **correct** code for this rule:
|
|
|
20
20
|
const answers = of(42, 54);
|
|
21
21
|
```
|
|
22
22
|
|
|
23
|
+
## When Not To Use It
|
|
24
|
+
|
|
25
|
+
If you use Finnish notation in your project, you should avoid this rule.
|
|
26
|
+
Or if you don't care if Finnish notation is used in your project, then you don't need this rule.
|
|
27
|
+
However, keep in mind that inconsistent style can harm readability in a project.
|
|
28
|
+
|
|
29
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
30
|
+
|
|
23
31
|
## Further reading
|
|
24
32
|
|
|
25
33
|
- [Observables and Finnish Notation](https://medium.com/@benlesh/observables-and-finnish-notation-df8356ed1c9b)
|
|
34
|
+
|
|
35
|
+
## Related To
|
|
36
|
+
|
|
37
|
+
- [`finnish`](./finnish.md)
|
|
38
|
+
|
|
39
|
+
## Resources
|
|
40
|
+
|
|
41
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-finnish.ts)
|
|
42
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-finnish.test.ts)
|
|
@@ -19,7 +19,7 @@ This rule will report observable-valued statements that are not treated in one o
|
|
|
19
19
|
|
|
20
20
|
> [!TIP]
|
|
21
21
|
> `no-floating-observables` only detects apparently unhandled observable _statements_.
|
|
22
|
-
> See [`no-misused-observables`](./no-misused-observables.md) for detecting code that provides observables to _logical_ locations
|
|
22
|
+
> See [`no-misused-observables`](./no-misused-observables.md) for detecting code that provides observables to _logical_ locations.
|
|
23
23
|
|
|
24
24
|
## Rule details
|
|
25
25
|
|
|
@@ -46,3 +46,23 @@ const answers = of(42, 54);
|
|
|
46
46
|
| `ignoreVoid` | Whether to ignore `void` expressions. | Boolean | `true` |
|
|
47
47
|
|
|
48
48
|
<!-- end auto-generated rule options list -->
|
|
49
|
+
|
|
50
|
+
## When Not To Use It
|
|
51
|
+
|
|
52
|
+
Like `@typescript-eslint/no-floating-promises`,
|
|
53
|
+
this rule can be difficult to enable on large existing projects that set up many floating observables.
|
|
54
|
+
Alternatively, if you're not worried about ignored errors or unhandled cold observables,
|
|
55
|
+
then in some cases it may be safe to not use this rule.
|
|
56
|
+
You might consider using `void`s and/or ESLint disable comments for those specific situations
|
|
57
|
+
instead of completely disabling this rule.
|
|
58
|
+
|
|
59
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
60
|
+
|
|
61
|
+
## Related To
|
|
62
|
+
|
|
63
|
+
- [`no-misused-observables`](./no-misused-observables.md)
|
|
64
|
+
|
|
65
|
+
## Resources
|
|
66
|
+
|
|
67
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-floating-observables.ts)
|
|
68
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-floating-observables.test.ts)
|
|
@@ -29,3 +29,15 @@ const sub = new Subject();
|
|
|
29
29
|
const result = firstValueFrom(sub, { defaultValue: null });
|
|
30
30
|
sub.complete();
|
|
31
31
|
```
|
|
32
|
+
|
|
33
|
+
## When Not To Use It
|
|
34
|
+
|
|
35
|
+
If you intentionally want `EmptyError` rejections when the observable completes, then you may not need this rule.
|
|
36
|
+
You might consider using ESLint disable comments for specific situations instead of completely disabling this rule.
|
|
37
|
+
|
|
38
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
39
|
+
|
|
40
|
+
## Resources
|
|
41
|
+
|
|
42
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-default-value.ts)
|
|
43
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-default-value.test.ts)
|
|
@@ -37,3 +37,17 @@ source.subscribe({
|
|
|
37
37
|
error: (error) => console.error(error)
|
|
38
38
|
});
|
|
39
39
|
```
|
|
40
|
+
|
|
41
|
+
## When Not To Use It
|
|
42
|
+
|
|
43
|
+
If you're not worried about ignored errors, then in some cases it may be safe to not use this rule.
|
|
44
|
+
Or if you use operators like `catchError` to handle all errors, then in some cases it may be safe to not use this rule.
|
|
45
|
+
You might consider using ESLint disable comments for those specific situations
|
|
46
|
+
instead of completely disabling this rule.
|
|
47
|
+
|
|
48
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
49
|
+
|
|
50
|
+
## Resources
|
|
51
|
+
|
|
52
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-error.ts)
|
|
53
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-error.test.ts)
|
|
@@ -8,6 +8,10 @@
|
|
|
8
8
|
|
|
9
9
|
This rule effects failures if the notifier passed to a `repeatWhen` or `retryWhen` callback is not used.
|
|
10
10
|
|
|
11
|
+
> [!NOTE]
|
|
12
|
+
> Both `repeatWhen` and `retryWhen` are deprecated by RxJS,
|
|
13
|
+
> so this rule may be removed in a future major version.
|
|
14
|
+
|
|
11
15
|
## Rule details
|
|
12
16
|
|
|
13
17
|
Examples of **incorrect** code for this rule:
|
|
@@ -30,3 +34,14 @@ const repeating = source.pipe(
|
|
|
30
34
|
repeatWhen(notifications => notifications.pipe(take(3)))
|
|
31
35
|
);
|
|
32
36
|
```
|
|
37
|
+
|
|
38
|
+
## When Not To Use It
|
|
39
|
+
|
|
40
|
+
If you don't use `repeatWhen` or `retryWhen` in your project, then you don't need this rule.
|
|
41
|
+
|
|
42
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
43
|
+
|
|
44
|
+
## Resources
|
|
45
|
+
|
|
46
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-notifier.ts)
|
|
47
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-notifier.test.ts)
|
|
@@ -36,3 +36,12 @@ const subject = new ReplaySubject<number>(Infinity);
|
|
|
36
36
|
import { of, shareReplay } from "rxjs";
|
|
37
37
|
of(42).pipe(shareReplay({ refCount: true, bufferSize: 1 }));
|
|
38
38
|
```
|
|
39
|
+
|
|
40
|
+
## When Not To Use It
|
|
41
|
+
|
|
42
|
+
If you don't care about implicitly defaulting to `Infinity` in your replay buffers, then you don't need this rule.
|
|
43
|
+
|
|
44
|
+
## Resources
|
|
45
|
+
|
|
46
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-replay-buffer.ts)
|
|
47
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-replay-buffer.test.ts)
|
|
@@ -26,3 +26,21 @@ import { of } from "rxjs";
|
|
|
26
26
|
|
|
27
27
|
of(42, 54).subscribe((value) => console.log(value));
|
|
28
28
|
```
|
|
29
|
+
|
|
30
|
+
## When Not To Use It
|
|
31
|
+
|
|
32
|
+
If you don't care about errors or output of some observables in your project, you may not need this rule.
|
|
33
|
+
Alternatively, you may require all logic to go in the `pipe` section of your observables.
|
|
34
|
+
In that case, you should not use this rule and should enable [`no-subscribe-handlers`](./no-subscribe-handlers.md) instead,
|
|
35
|
+
which is the opposite of this rule.
|
|
36
|
+
|
|
37
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
38
|
+
|
|
39
|
+
## Related To
|
|
40
|
+
|
|
41
|
+
- [`no-subscribe-handlers`](./no-subscribe-handlers.md)
|
|
42
|
+
|
|
43
|
+
## Resources
|
|
44
|
+
|
|
45
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-subscribe.ts)
|
|
46
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-subscribe.test.ts)
|
|
@@ -31,3 +31,16 @@ const numbers = new Observable<number>(subscriber => {
|
|
|
31
31
|
interval(1e3).subscribe(subscriber);
|
|
32
32
|
});
|
|
33
33
|
```
|
|
34
|
+
|
|
35
|
+
## When Not To Use It
|
|
36
|
+
|
|
37
|
+
If you don't care about unsubscribing from all observables in your project, then you may not need this rule.
|
|
38
|
+
Alternatively, your project might use operators like `take`, `takeUntil`, `takeWhile`, etc.
|
|
39
|
+
or Angular's `takeUntilDestroyed` to automatically handle subscriptions.
|
|
40
|
+
|
|
41
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
42
|
+
|
|
43
|
+
## Resources
|
|
44
|
+
|
|
45
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-subscription.ts)
|
|
46
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-subscription.test.ts)
|
|
@@ -24,3 +24,12 @@ import { takeWhile } from "rxjs/operators";
|
|
|
24
24
|
|
|
25
25
|
const whilst = source.pipe(takeWhile(value => value));
|
|
26
26
|
```
|
|
27
|
+
|
|
28
|
+
## When Not To Use It
|
|
29
|
+
|
|
30
|
+
If you don't care about using the given value in a `takeWhile` callback, then you don't need this rule.
|
|
31
|
+
|
|
32
|
+
## Resources
|
|
33
|
+
|
|
34
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-ignored-takewhile-value.ts)
|
|
35
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-ignored-takewhile-value.test.ts)
|
|
@@ -8,7 +8,10 @@
|
|
|
8
8
|
|
|
9
9
|
<!-- end auto-generated rule header -->
|
|
10
10
|
|
|
11
|
-
This rule requires an explicit type annotation for error parameters in error handlers.
|
|
11
|
+
This rule requires an explicit type annotation for error parameters in error handlers.
|
|
12
|
+
It's similar to the typescript-eslint [`use-unknown-in-catch-callback-variable`](https://typescript-eslint.io/rules/use-unknown-in-catch-callback-variable/) rule
|
|
13
|
+
or the TSConfig [`useUnknownInCatchVariables`](https://www.typescriptlang.org/tsconfig/#useUnknownInCatchVariables) option,
|
|
14
|
+
but is for observables - not `try`/`catch` statements.
|
|
12
15
|
|
|
13
16
|
## Rule details
|
|
14
17
|
|
|
@@ -89,6 +92,18 @@ This rule accepts a single option which is an object with an `allowExplicitAny`
|
|
|
89
92
|
}
|
|
90
93
|
```
|
|
91
94
|
|
|
95
|
+
## When Not To Use It
|
|
96
|
+
|
|
97
|
+
If your codebase is not yet able to enable `useUnknownInCatchVariables`,
|
|
98
|
+
it likely would be similarly difficult to enable this rule.
|
|
99
|
+
|
|
100
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
101
|
+
|
|
92
102
|
## Further reading
|
|
93
103
|
|
|
94
104
|
- [Catching Unknowns](https://ncjamieson.com/catching-unknowns/)
|
|
105
|
+
|
|
106
|
+
## Resources
|
|
107
|
+
|
|
108
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-implicit-any-catch.ts)
|
|
109
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-implicit-any-catch.test.ts)
|
package/docs/rules/no-index.md
CHANGED
|
@@ -19,3 +19,16 @@ Examples of **correct** code for this rule:
|
|
|
19
19
|
```ts
|
|
20
20
|
import { of } from "rxjs";
|
|
21
21
|
```
|
|
22
|
+
|
|
23
|
+
## When Not To Use It
|
|
24
|
+
|
|
25
|
+
If you don't care about unnecessary import path segments, then you don't need this rule.
|
|
26
|
+
|
|
27
|
+
## Further reading
|
|
28
|
+
|
|
29
|
+
- [Importing instructions](https://rxjs.dev/guide/importing)
|
|
30
|
+
|
|
31
|
+
## Resources
|
|
32
|
+
|
|
33
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-index.ts)
|
|
34
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-index.test.ts)
|
|
@@ -21,3 +21,18 @@ Examples of **correct** code for this rule:
|
|
|
21
21
|
```ts
|
|
22
22
|
import { of } from "rxjs";
|
|
23
23
|
```
|
|
24
|
+
|
|
25
|
+
## When Not To Use It
|
|
26
|
+
|
|
27
|
+
If you need to import internal modules that are not covered by the public API,
|
|
28
|
+
then you don't need this rule.
|
|
29
|
+
However, keep in mind that internal modules may change without notice.
|
|
30
|
+
|
|
31
|
+
## Further reading
|
|
32
|
+
|
|
33
|
+
- [Importing instructions](https://rxjs.dev/guide/importing)
|
|
34
|
+
|
|
35
|
+
## Resources
|
|
36
|
+
|
|
37
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-internal.ts)
|
|
38
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-internal.test.ts)
|
|
@@ -80,6 +80,22 @@ You can disable selective parts of the `checksVoidReturn` option. The following
|
|
|
80
80
|
| `returns` | Disallow returning an Observable-returning function where a function that returns `void` is expected. | Boolean | `true` |
|
|
81
81
|
| `variables` | Disallow assigning or declaring an Observable-returning function where a function that returns `void` is expected. | Boolean | `true` |
|
|
82
82
|
|
|
83
|
+
## When Not To Use It
|
|
84
|
+
|
|
85
|
+
Like `@typescript-eslint/no-misused-promises`,
|
|
86
|
+
this rule can be difficult to enable on large existing projects that set up many misused observables.
|
|
87
|
+
|
|
88
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
89
|
+
|
|
83
90
|
## Further reading
|
|
84
91
|
|
|
85
92
|
- [TypeScript void function assignability](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void)
|
|
93
|
+
|
|
94
|
+
## Related To
|
|
95
|
+
|
|
96
|
+
- [`no-floating-observables`](./no-floating-observables.md)
|
|
97
|
+
|
|
98
|
+
## Resources
|
|
99
|
+
|
|
100
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-misused-observables.ts)
|
|
101
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-misused-observables.test.ts)
|
|
@@ -30,3 +30,17 @@ of(42, 54).pipe(
|
|
|
30
30
|
mergeMap((value) => timer(1e3).pipe(map(() => value)))
|
|
31
31
|
).subscribe((value) => console.log(value));
|
|
32
32
|
```
|
|
33
|
+
|
|
34
|
+
## When Not To Use It
|
|
35
|
+
|
|
36
|
+
If you need nested subscriptions and are aware of the potential issues,
|
|
37
|
+
then you might not need this rule.
|
|
38
|
+
However, you should typically prefer to use higher-order mapping operators
|
|
39
|
+
like `mergeMap`, `switchMap`, or `concatMap` to handle nested observables.
|
|
40
|
+
|
|
41
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
42
|
+
|
|
43
|
+
## Resources
|
|
44
|
+
|
|
45
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-nested-subscribe.ts)
|
|
46
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-nested-subscribe.test.ts)
|
|
@@ -6,7 +6,8 @@
|
|
|
6
6
|
|
|
7
7
|
<!-- end auto-generated rule header -->
|
|
8
8
|
|
|
9
|
-
This rule effects failures if an attempt is made to send a notification to an observer after a `complete` or `error` notification has already been sent
|
|
9
|
+
This rule effects failures if an attempt is made to send a notification to an observer after a `complete` or `error` notification has already been sent,
|
|
10
|
+
or if `unsubscribe` has been called.
|
|
10
11
|
|
|
11
12
|
Note that the rule _does not perform extensive analysis_. It uses a straightforward and limited approach to catch obviously redundant notifications.
|
|
12
13
|
|
|
@@ -32,3 +33,18 @@ const subject = new Subject<number>();
|
|
|
32
33
|
subject.next(42);
|
|
33
34
|
subject.error(new Error("Kaboom!"));
|
|
34
35
|
```
|
|
36
|
+
|
|
37
|
+
## When Not To Use It
|
|
38
|
+
|
|
39
|
+
If you don't care about redundant notifications, then you don't need this rule.
|
|
40
|
+
|
|
41
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
42
|
+
|
|
43
|
+
## Related To
|
|
44
|
+
|
|
45
|
+
- [`no-subject-unsubscribe`](./no-subject-unsubscribe.md)
|
|
46
|
+
|
|
47
|
+
## Resources
|
|
48
|
+
|
|
49
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-redundant-notify.ts)
|
|
50
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-redundant-notify.test.ts)
|
|
@@ -29,6 +29,21 @@ This rule accepts a single option which is an object with an `allowConfig` prope
|
|
|
29
29
|
}
|
|
30
30
|
```
|
|
31
31
|
|
|
32
|
+
## When Not To Use It
|
|
33
|
+
|
|
34
|
+
If you are confident that `shareReplay` is used properly your project,
|
|
35
|
+
then you may not need this rule.
|
|
36
|
+
However, keep in mind that it's recommended to always provide a config object
|
|
37
|
+
that explicitly specifies `refCount` (see linked blog post);
|
|
38
|
+
by default, `shareReplay` without any config defaults to `refCount: false`,
|
|
39
|
+
which means the source observable will never be unsubscribed from,
|
|
40
|
+
potentially leading to unexpected behavior and memory leaks.
|
|
41
|
+
|
|
32
42
|
## Further reading
|
|
33
43
|
|
|
34
44
|
- [What's changed with shareReplay](https://ncjamieson.com/whats-changed-with-sharereplay/)
|
|
45
|
+
|
|
46
|
+
## Resources
|
|
47
|
+
|
|
48
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-sharereplay.ts)
|
|
49
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-sharereplay.test.ts)
|
|
@@ -7,3 +7,17 @@
|
|
|
7
7
|
<!-- end auto-generated rule header -->
|
|
8
8
|
|
|
9
9
|
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.
|
|
10
|
+
|
|
11
|
+
## When Not To Use It
|
|
12
|
+
|
|
13
|
+
If you need to subclass RxJS classes in your project, then don't use this rule.
|
|
14
|
+
However, keep in mind that implementation details may change in the future;
|
|
15
|
+
You might consider using ESLint disable comments for specific situations
|
|
16
|
+
instead of completely disabling this rule.
|
|
17
|
+
|
|
18
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
19
|
+
|
|
20
|
+
## Resources
|
|
21
|
+
|
|
22
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subclass.ts)
|
|
23
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subclass.test.ts)
|
|
@@ -6,8 +6,58 @@
|
|
|
6
6
|
|
|
7
7
|
<!-- end auto-generated rule header -->
|
|
8
8
|
|
|
9
|
-
This rule effects failures if the `unsubscribe` method is called on subjects.
|
|
9
|
+
This rule effects failures if the `unsubscribe` method is called on subjects.
|
|
10
|
+
The method behaves differently to the `unsubscribe` method on subscriptions and is often an error.
|
|
11
|
+
|
|
12
|
+
This rule also effects failures if a subject is passed to a subscription's `add` method.
|
|
13
|
+
Adding a subject to a subscription will cause the subject's `unsubscribe` method to get called
|
|
14
|
+
when the subscription is unsubscribed.
|
|
15
|
+
|
|
16
|
+
## Rule details
|
|
17
|
+
|
|
18
|
+
Examples of **incorrect** code for this rule:
|
|
19
|
+
|
|
20
|
+
```ts
|
|
21
|
+
import { Subject } from "rxjs";
|
|
22
|
+
|
|
23
|
+
const subject = new Subject<number>();
|
|
24
|
+
subject.unsubscribe();
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
```ts
|
|
28
|
+
import { Subject, Subscription } from "rxjs";
|
|
29
|
+
|
|
30
|
+
const subject = new Subject<number>();
|
|
31
|
+
const subscription = new Subscription();
|
|
32
|
+
subscription.add(subject);
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Examples of **correct** code for this rule:
|
|
36
|
+
|
|
37
|
+
```ts
|
|
38
|
+
import { Subject } from "rxjs";
|
|
39
|
+
|
|
40
|
+
const subject = new Subject<number>();
|
|
41
|
+
subject.complete();
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
## When Not To Use It
|
|
45
|
+
|
|
46
|
+
If you intentionally use `unsubscribe` to cause errors when subjects are `next`-ed after closing,
|
|
47
|
+
then you don't need this rule.
|
|
48
|
+
|
|
49
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
10
50
|
|
|
11
51
|
## Further reading
|
|
12
52
|
|
|
13
53
|
- [Closed Subjects](https://ncjamieson.com/closed-subjects/)
|
|
54
|
+
- [Composing Subscription](https://ncjamieson.com/composing-subscriptions/)
|
|
55
|
+
|
|
56
|
+
## Related To
|
|
57
|
+
|
|
58
|
+
- [`no-redundant-notify`](./no-redundant-notify.md)
|
|
59
|
+
|
|
60
|
+
## Resources
|
|
61
|
+
|
|
62
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subject-unsubscribe.ts)
|
|
63
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subject-unsubscribe.test.ts)
|
|
@@ -5,3 +5,15 @@
|
|
|
5
5
|
<!-- end auto-generated rule header -->
|
|
6
6
|
|
|
7
7
|
This rule effects an error if the `value` property - or `getValue` method - of a `BehaviorSubject` is used.
|
|
8
|
+
|
|
9
|
+
## When Not To Use It
|
|
10
|
+
|
|
11
|
+
If your code uses the `value` property or the `getValue` method of `BehaviorSubject`,
|
|
12
|
+
then don't enable this rule.
|
|
13
|
+
|
|
14
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
15
|
+
|
|
16
|
+
## Resources
|
|
17
|
+
|
|
18
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subject-value.ts)
|
|
19
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subject-value.test.ts)
|
|
@@ -35,3 +35,19 @@ of(42, 54)
|
|
|
35
35
|
.pipe(tap((value) => console.log(value)))
|
|
36
36
|
.subscribe();
|
|
37
37
|
```
|
|
38
|
+
|
|
39
|
+
## When Not To Use It
|
|
40
|
+
|
|
41
|
+
If you don't require all logic to go in the `pipe` section of your observables, then you don't need this rule.
|
|
42
|
+
Also, if your project uses `no-ignored-subscribe`, which is the opposite of this rule, then you should not use this rule.
|
|
43
|
+
|
|
44
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
45
|
+
|
|
46
|
+
## Related To
|
|
47
|
+
|
|
48
|
+
- [`no-ignored-subscribe`](./no-ignored-subscribe.md)
|
|
49
|
+
|
|
50
|
+
## Resources
|
|
51
|
+
|
|
52
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subscribe-handlers.ts)
|
|
53
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subscribe-handlers.test.ts)
|
|
@@ -18,7 +18,7 @@ import { map } from "rxjs/operators";
|
|
|
18
18
|
|
|
19
19
|
of(42, 54).pipe(
|
|
20
20
|
map(value => {
|
|
21
|
-
of(value).subscribe(console.log);
|
|
21
|
+
of(value).subscribe(console.log);
|
|
22
22
|
return value * 2;
|
|
23
23
|
})
|
|
24
24
|
).subscribe(result => console.log(result));
|
|
@@ -35,3 +35,21 @@ of(42, 54).pipe(
|
|
|
35
35
|
map(value => value * 2)
|
|
36
36
|
).subscribe(result => console.log(result));
|
|
37
37
|
```
|
|
38
|
+
|
|
39
|
+
## When Not To Use It
|
|
40
|
+
|
|
41
|
+
If you need to subscribe within `pipe` and are aware of the potential issues,
|
|
42
|
+
then you might not need this rule.
|
|
43
|
+
However, you should typically prefer to use higher-order mapping operators
|
|
44
|
+
like `mergeMap`, `switchMap`, or `concatMap` to handle nested observables.
|
|
45
|
+
|
|
46
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
47
|
+
|
|
48
|
+
## Related To
|
|
49
|
+
|
|
50
|
+
- [`no-nested-subscribe`](./no-nested-subscribe.md)
|
|
51
|
+
|
|
52
|
+
## Resources
|
|
53
|
+
|
|
54
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subscribe-in-pipe.ts)
|
|
55
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subscribe-in-pipe.test.ts)
|
|
@@ -10,6 +10,23 @@
|
|
|
10
10
|
|
|
11
11
|
This rule effects failures if the `toPromise` method is used.
|
|
12
12
|
|
|
13
|
+
This rule provides two editor suggestions which replace `toPromise` with either:
|
|
14
|
+
|
|
15
|
+
- `lastValueFrom(...)`, which behaves closest to the behavior of `toPromise`,
|
|
16
|
+
- or `firstValueFrom(...)`.
|
|
17
|
+
|
|
18
|
+
## When Not To Use It
|
|
19
|
+
|
|
20
|
+
If you rely on RxJS's deprecation of `toPromise` and don't need to double-flag usage,
|
|
21
|
+
then you don't need this rule.
|
|
22
|
+
|
|
23
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
24
|
+
|
|
13
25
|
## Further reading
|
|
14
26
|
|
|
15
27
|
- [Conversion to Promises](https://rxjs.dev/deprecations/to-promise)
|
|
28
|
+
|
|
29
|
+
## Resources
|
|
30
|
+
|
|
31
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-topromise.ts)
|
|
32
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-topromise.test.ts)
|
|
@@ -41,6 +41,21 @@ return this.http
|
|
|
41
41
|
);
|
|
42
42
|
```
|
|
43
43
|
|
|
44
|
+
## When Not To Use It
|
|
45
|
+
|
|
46
|
+
If every handler in your project does not depend on the `this` context in their implementations,
|
|
47
|
+
then in some cases it may be safe to not use this rule.
|
|
48
|
+
However, keep in mind that future changes may introduce bugs
|
|
49
|
+
by changing their implementations to depend on the `this` context;
|
|
50
|
+
see the linked blog post for best practice explanation.
|
|
51
|
+
|
|
52
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
53
|
+
|
|
44
54
|
## Further reading
|
|
45
55
|
|
|
46
56
|
- [Avoiding unbound methods](https://ncjamieson.com/avoiding-unbound-methods/)
|
|
57
|
+
|
|
58
|
+
## Resources
|
|
59
|
+
|
|
60
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unbound-methods.ts)
|
|
61
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unbound-methods.test.ts)
|
|
@@ -60,3 +60,15 @@ This rule accepts a single option which is an object with an `observable` proper
|
|
|
60
60
|
]
|
|
61
61
|
}
|
|
62
62
|
```
|
|
63
|
+
|
|
64
|
+
## When Not To Use It
|
|
65
|
+
|
|
66
|
+
If you don't use a library with effects and epics (e.g. NgRx or redux-observable),
|
|
67
|
+
then you don't need this rule.
|
|
68
|
+
|
|
69
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
70
|
+
|
|
71
|
+
## Resources
|
|
72
|
+
|
|
73
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-catch.ts)
|
|
74
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-catch.test.ts)
|
|
@@ -26,3 +26,15 @@ This rule accepts a single option which is an object with an `observable` proper
|
|
|
26
26
|
]
|
|
27
27
|
}
|
|
28
28
|
```
|
|
29
|
+
|
|
30
|
+
## When Not To Use It
|
|
31
|
+
|
|
32
|
+
If you don't use a library with effects and epics (e.g. NgRx or redux-observable),
|
|
33
|
+
then you don't need this rule.
|
|
34
|
+
|
|
35
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
36
|
+
|
|
37
|
+
## Resources
|
|
38
|
+
|
|
39
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-first.ts)
|
|
40
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-first.test.ts)
|
|
@@ -8,7 +8,8 @@
|
|
|
8
8
|
|
|
9
9
|
This rule effects failures if `next` is called without an argument and the subject's value type is not `void`.
|
|
10
10
|
|
|
11
|
-
In RxJS version 6, the `next` method's `value` parameter
|
|
11
|
+
In RxJS version 6, the `next` method's `value` parameter was optional, but a value should always be specified for subjects with non-`void` element types.
|
|
12
|
+
RxJS version 7 changed the `value` parameter to mandatory.
|
|
12
13
|
|
|
13
14
|
## Rule details
|
|
14
15
|
|
|
@@ -30,3 +31,16 @@ subject.next();
|
|
|
30
31
|
const subject = new Subject<number>();
|
|
31
32
|
subject.next(0);
|
|
32
33
|
```
|
|
34
|
+
|
|
35
|
+
## When Not To Use It
|
|
36
|
+
|
|
37
|
+
If you don't care about sending `undefined` to subjects, then you don't need this rule.
|
|
38
|
+
Alternatively, you may rely on TypeScript to enforce the `value` parameter,
|
|
39
|
+
which was made mandatory in RxJS version 7.
|
|
40
|
+
|
|
41
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
42
|
+
|
|
43
|
+
## Resources
|
|
44
|
+
|
|
45
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-subject-next.ts)
|
|
46
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-subject-next.test.ts)
|
|
@@ -47,6 +47,18 @@ The `allow` or `disallow` properties are mutually exclusive. Whether or not `swi
|
|
|
47
47
|
|
|
48
48
|
The properties in the options object are themselves optional; they do not all have to be specified.
|
|
49
49
|
|
|
50
|
+
## When Not To Use It
|
|
51
|
+
|
|
52
|
+
If you don't use a library with effects and epics (e.g. NgRx or redux-observable),
|
|
53
|
+
then you don't need this rule.
|
|
54
|
+
|
|
55
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
56
|
+
|
|
50
57
|
## Further reading
|
|
51
58
|
|
|
52
59
|
- [Avoiding switchMap-related bugs](https://ncjamieson.com/avoiding-switchmap-related-bugs/)
|
|
60
|
+
|
|
61
|
+
## Resources
|
|
62
|
+
|
|
63
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-switchmap.ts)
|
|
64
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-switchmap.test.ts)
|
|
@@ -56,6 +56,17 @@ By default, the `allow` property contains all of the built-in operators that are
|
|
|
56
56
|
|
|
57
57
|
The properties in the options object are themselves optional; they do not all have to be specified.
|
|
58
58
|
|
|
59
|
+
## When Not To Use It
|
|
60
|
+
|
|
61
|
+
If you are confident your project uses `takeUntil` correctly, then you may not need this rule.
|
|
62
|
+
|
|
63
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
64
|
+
|
|
59
65
|
## Further reading
|
|
60
66
|
|
|
61
67
|
- [Avoiding takeUntil leaks](https://ncjamieson.com/avoiding-takeuntil-leaks/)
|
|
68
|
+
|
|
69
|
+
## Resources
|
|
70
|
+
|
|
71
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-takeuntil.ts)
|
|
72
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-takeuntil.test.ts)
|
|
@@ -49,6 +49,18 @@ This rule accepts a single option which is an object with an `allowNext` propert
|
|
|
49
49
|
}
|
|
50
50
|
```
|
|
51
51
|
|
|
52
|
+
## When Not To Use It
|
|
53
|
+
|
|
54
|
+
If you rely on RxJS's deprecation of separate handlers and don't need to double-flag usage,
|
|
55
|
+
then you don't need this rule.
|
|
56
|
+
|
|
57
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
58
|
+
|
|
52
59
|
## Further reading
|
|
53
60
|
|
|
54
61
|
- [Subscribe Arguments](https://rxjs.dev/deprecations/subscribe-arguments)
|
|
62
|
+
|
|
63
|
+
## Resources
|
|
64
|
+
|
|
65
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/prefer-observer.ts)
|
|
66
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/prefer-observer.test.ts)
|
|
@@ -29,6 +29,17 @@ Examples of **correct** code for this rule:
|
|
|
29
29
|
import { map } from 'rxjs';
|
|
30
30
|
```
|
|
31
31
|
|
|
32
|
+
## When Not To Use It
|
|
33
|
+
|
|
34
|
+
If you don't care about importing from the deprecated site, then you don't need this rule.
|
|
35
|
+
|
|
36
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
37
|
+
|
|
32
38
|
## Further reading
|
|
33
39
|
|
|
34
40
|
- [Importing instructions](https://rxjs.dev/guide/importing)
|
|
41
|
+
|
|
42
|
+
## Resources
|
|
43
|
+
|
|
44
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/prefer-root-operators.ts)
|
|
45
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/prefer-root-operators.test.ts)
|
|
@@ -6,6 +6,10 @@
|
|
|
6
6
|
|
|
7
7
|
This rule effects failures if subject variables, properties and parameters don't conform to a naming scheme that identifies them as subjects.
|
|
8
8
|
|
|
9
|
+
> [!NOTE]
|
|
10
|
+
> This rule is designed to be optionally compatible with [`finnish`](./finnish.md).
|
|
11
|
+
> Using Finnish notation (adding a `$` suffix) your subject names will _not_ cause a failure of this rule.
|
|
12
|
+
|
|
9
13
|
## Rule details
|
|
10
14
|
|
|
11
15
|
Examples of **incorrect** code for this rule:
|
|
@@ -18,6 +22,7 @@ Examples of **correct** code for this rule:
|
|
|
18
22
|
|
|
19
23
|
```ts
|
|
20
24
|
const answersSubject = new Subject<number>();
|
|
25
|
+
const answersSubject$ = new Subject<number>();
|
|
21
26
|
```
|
|
22
27
|
|
|
23
28
|
## Options
|
|
@@ -34,7 +39,9 @@ const answersSubject = new Subject<number>();
|
|
|
34
39
|
|
|
35
40
|
<!-- end auto-generated rule options list -->
|
|
36
41
|
|
|
37
|
-
This rule accepts a single option which is an object with properties that determine whether
|
|
42
|
+
This rule accepts a single option which is an object with properties that determine whether subject suffixes are enforced for `parameters`, `properties` and `variables`.
|
|
43
|
+
It also contains a `types` property that determine whether or not the naming convention is to be enforced for specific types
|
|
44
|
+
and a `suffix` property.
|
|
38
45
|
|
|
39
46
|
The default (Angular-friendly) configuration looks like this:
|
|
40
47
|
|
|
@@ -56,3 +63,19 @@ The default (Angular-friendly) configuration looks like this:
|
|
|
56
63
|
```
|
|
57
64
|
|
|
58
65
|
The properties in the options object are themselves optional; they do not all have to be specified.
|
|
66
|
+
|
|
67
|
+
## When Not To Use It
|
|
68
|
+
|
|
69
|
+
If you don't use suffixes on your project's subjects, then you don't need this rule.
|
|
70
|
+
However, keep in mind that inconsistent style can harm readability in a project.
|
|
71
|
+
|
|
72
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
73
|
+
|
|
74
|
+
## Related To
|
|
75
|
+
|
|
76
|
+
- [`finnish`](./finnish.md)
|
|
77
|
+
|
|
78
|
+
## Resources
|
|
79
|
+
|
|
80
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/suffix-subjects.ts)
|
|
81
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/suffix-subjects.test.ts)
|
|
@@ -38,3 +38,16 @@ throwError(() => new Error("Kaboom!"));
|
|
|
38
38
|
| `allowThrowingUnknown` | Whether to always allow throwing values typed as `unknown`. | Boolean | `true` |
|
|
39
39
|
|
|
40
40
|
<!-- end auto-generated rule options list -->
|
|
41
|
+
|
|
42
|
+
## When Not To Use It
|
|
43
|
+
|
|
44
|
+
If you don't care about throwing values that are not `Error` objects, then you don't need this rule.
|
|
45
|
+
However, keep in mind that, while JavaScript _allows_ throwing any value,
|
|
46
|
+
most developer may find this behavior surprising or inconvenient to handle.
|
|
47
|
+
|
|
48
|
+
Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
|
|
49
|
+
|
|
50
|
+
## Resources
|
|
51
|
+
|
|
52
|
+
- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/throw-error.ts)
|
|
53
|
+
- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/throw-error.test.ts)
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "eslint-plugin-rxjs-x",
|
|
3
3
|
"type": "commonjs",
|
|
4
|
-
"version": "0.6.
|
|
5
|
-
"packageManager": "yarn@4.
|
|
4
|
+
"version": "0.6.2",
|
|
5
|
+
"packageManager": "yarn@4.6.0+sha512.5383cc12567a95f1d668fbe762dfe0075c595b4bfff433be478dbbe24e05251a8e8c3eb992a986667c1d53b6c3a9c85b8398c35a960587fbd9fa3a0915406728",
|
|
6
6
|
"description": "ESLint v9+ plugin for RxJS",
|
|
7
7
|
"author": "Jason Weinzierl <weinzierljason@gmail.com>",
|
|
8
8
|
"license": "MIT",
|
|
@@ -73,27 +73,27 @@
|
|
|
73
73
|
}
|
|
74
74
|
},
|
|
75
75
|
"devDependencies": {
|
|
76
|
-
"@eslint/js": "^9.
|
|
77
|
-
"@stylistic/eslint-plugin": "^2.
|
|
76
|
+
"@eslint/js": "^9.17.0",
|
|
77
|
+
"@stylistic/eslint-plugin": "^2.12.1",
|
|
78
78
|
"@types/common-tags": "^1.8.4",
|
|
79
79
|
"@types/node": "~18.18.0",
|
|
80
|
-
"@typescript-eslint/rule-tester": "^8.
|
|
80
|
+
"@typescript-eslint/rule-tester": "^8.19.1",
|
|
81
81
|
"@typescript/vfs": "^1.6.0",
|
|
82
82
|
"@vitest/coverage-v8": "^2.1.8",
|
|
83
|
-
"@vitest/eslint-plugin": "^1.1.
|
|
84
|
-
"bumpp": "^9.
|
|
85
|
-
"eslint": "^9.
|
|
83
|
+
"@vitest/eslint-plugin": "^1.1.24",
|
|
84
|
+
"bumpp": "^9.9.3",
|
|
85
|
+
"eslint": "^9.17.0",
|
|
86
86
|
"eslint-config-flat-gitignore": "^0.3.0",
|
|
87
|
-
"eslint-doc-generator": "^
|
|
88
|
-
"eslint-import-resolver-typescript": "^3.
|
|
89
|
-
"eslint-plugin-eslint-plugin": "^6.
|
|
90
|
-
"eslint-plugin-import-x": "^4.
|
|
91
|
-
"eslint-plugin-n": "^17.
|
|
92
|
-
"markdownlint-cli2": "^0.
|
|
87
|
+
"eslint-doc-generator": "^2.0.2",
|
|
88
|
+
"eslint-import-resolver-typescript": "^3.7.0",
|
|
89
|
+
"eslint-plugin-eslint-plugin": "^6.4.0",
|
|
90
|
+
"eslint-plugin-import-x": "^4.6.1",
|
|
91
|
+
"eslint-plugin-n": "^17.15.1",
|
|
92
|
+
"markdownlint-cli2": "^0.17.1",
|
|
93
93
|
"rxjs": "^7.8.1",
|
|
94
94
|
"tsup": "^8.3.5",
|
|
95
95
|
"typescript": "~5.7.2",
|
|
96
|
-
"typescript-eslint": "^8.
|
|
96
|
+
"typescript-eslint": "^8.19.1",
|
|
97
97
|
"vitest": "^2.1.8"
|
|
98
98
|
},
|
|
99
99
|
"engines": {
|