eslint-plugin-rxjs-x 0.7.0 → 0.7.2

package/docs/rules/no-internal.md

@@ -1,38 +0,0 @@
-# Disallow importing internal modules (`rxjs-x/no-internal`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-🔧💡 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix) and manually fixable by [editor suggestions](https://eslint.org/docs/latest/use/core-concepts#rule-suggestions).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if an internal module is specified as the import location.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { of } from "rxjs/internal/observable/of";
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { of } from "rxjs";
-```
-
-## When Not To Use It
-
-If you need to import internal modules that are not covered by the public API,
-then you don't need this rule.
-However, keep in mind that internal modules may change without notice.
-
-## Further reading
-
-- [Importing instructions](https://rxjs.dev/guide/importing)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-internal.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-internal.test.ts)

package/docs/rules/no-misused-observables.md

@@ -1,101 +0,0 @@
-# Disallow Observables in places not designed to handle them (`rxjs-x/no-misused-observables`)
-
-💼 This rule is enabled in the 🔒 `strict` config.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule forbids providing observables to logical locations where the TypeScript compiler allows them but they are not handled properly.
-These situations can often arise due to a misunderstanding of the way observables are handled.
-
-> [!TIP]
-> `no-misused-observables` only detects code that provides observables to incorrect _logical_ locations.
-> See [`no-floating-observables`](./no-floating-observables.md) for detecting unhandled observable _statements_.
-
-This rule is like [no-misused-promises](https://typescript-eslint.io/rules/no-misused-promises) but for Observables.
-
-> [!NOTE]
-> Unlike `@typescript-eslint/no-misused-promises`, this rule does not check conditionals like `if` statements.
-> Use `@typescript-eslint/no-unnecessary-condition` for linting those situations.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { of } from "rxjs";
-
-[1, 2, 3].forEach(i => of(i));
-
-interface MySyncInterface {
-    foo(): void;
-}
-class MyRxClass implements MySyncInterface {
-    foo(): Observable<number> {
-        return of(42);
-    }
-}
-
-const a = of(42);
-const b = { ...b };
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { of } from "rxjs";
-
-[1, 2, 3].map(i => of(i));
-
-interface MyRxInterface {
-    foo(): Observable<number>;
-}
-class MyRxClass implements MyRxInterface {
-    foo(): Observable<number> {
-        return of(42);
-    }
-}
-```
-
-## Options
-
-<!-- WARNING: not auto-generated! -->
-
-| Name               | Description                                                                 | Type    | Default |
-| :----------------- | :-------------------------------------------------------------------------- | :------ | :------ |
-| `checksSpreads`    | Disallow `...` spreading an Observable.                                     | Boolean | `true`  |
-| `checksVoidReturn` | Disallow returning an Observable from a function typed as returning `void`. | Object  | `true`  |
-
-### `checksVoidReturn`
-
-You can disable selective parts of the `checksVoidReturn` option. The following sub-options are supported:
-
-| Name               | Description                                                                                                                              | Type    | Default |
-| :----------------- | :--------------------------------------------------------------------------------------------------------------------------------------- | :------ | :------ |
-| `arguments`        | Disallow passing an Observable-returning function as an argument where the parameter type expects a function that returns `void`.        | Boolean | `true`  |
-| `attributes`       | Disallow passing an Observable-returning function as a JSX attribute expected to be a function that returns `void`.                      | Boolean | `true`  |
-| `inheritedMethods` | Disallow providing an Observable-returning function where a function that returns `void` is expected by an extended or implemented type. | Boolean | `true`  |
-| `properties`       | Disallow providing an Observable-returning function where a function that returns `void` is expected by a property.                      | Boolean | `true`  |
-| `returns`          | Disallow returning an Observable-returning function where a function that returns `void` is expected.                                    | Boolean | `true`  |
-| `variables`        | Disallow assigning or declaring an Observable-returning function where a function that returns `void` is expected.                       | Boolean | `true`  |
-
-## When Not To Use It
-
-Like `@typescript-eslint/no-misused-promises`,
-this rule can be difficult to enable on large existing projects that set up many misused observables.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Further reading
-
-- [TypeScript void function assignability](https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-functions-returning-non-void-assignable-to-function-returning-void)
-
-## Related To
-
-- [`no-floating-observables`](./no-floating-observables.md)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-misused-observables.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-misused-observables.test.ts)

package/docs/rules/no-nested-subscribe.md

@@ -1,46 +0,0 @@
-# Disallow calling `subscribe` within a `subscribe` callback (`rxjs-x/no-nested-subscribe`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if `subscribe` is called within a `subscribe` handler.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { of, timer } from "rxjs";
-
-of(42, 54).subscribe((value) => {
-  timer(1e3).subscribe(() => console.log(value));
-});
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { of, timer } from "rxjs";
-import { map, mergeMap } from "rxjs/operators";
-
-of(42, 54).pipe(
-  mergeMap((value) => timer(1e3).pipe(map(() => value)))
-).subscribe((value) => console.log(value));
-```
-
-## When Not To Use It
-
-If you need nested subscriptions and are aware of the potential issues,
-then you might not need this rule.
-However, you should typically prefer to use higher-order mapping operators
-like `mergeMap`, `switchMap`, or `concatMap` to handle nested observables.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-nested-subscribe.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-nested-subscribe.test.ts)

package/docs/rules/no-redundant-notify.md

@@ -1,50 +0,0 @@
-# Disallow sending redundant notifications from completed or errored observables (`rxjs-x/no-redundant-notify`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-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,
-or if `unsubscribe` has been called.
-
-Note that the rule _does not perform extensive analysis_. It uses a straightforward and limited approach to catch obviously redundant notifications.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { Subject } from "rxjs";
-
-const subject = new Subject<number>();
-subject.next(42);
-subject.error(new Error("Kaboom!"));
-subject.complete();
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { Subject } from "rxjs";
-
-const subject = new Subject<number>();
-subject.next(42);
-subject.error(new Error("Kaboom!"));
-```
-
-## When Not To Use It
-
-If you don't care about redundant notifications, then you don't need this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Related To
-
-- [`no-subject-unsubscribe`](./no-subject-unsubscribe.md)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-redundant-notify.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-redundant-notify.test.ts)

package/docs/rules/no-sharereplay.md

@@ -1,49 +0,0 @@
-# Disallow unsafe `shareReplay` usage (`rxjs-x/no-sharereplay`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if the `shareReplay` operator is used - or if it is used without specifying a `config` argument.
-
-The behavior of `shareReplay` has changed several times - see the blog post linked below.
-
-## Options
-
-<!-- begin auto-generated rule options list -->
-
-| Name          | Description                                          | Type    | Default |
-| :------------ | :--------------------------------------------------- | :------ | :------ |
-| `allowConfig` | Allow shareReplay if a config argument is specified. | Boolean | `true`  |
-
-<!-- end auto-generated rule options list -->
-
-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`.
-
-```json
-{
-  "rxjs-x/no-sharereplay": [
-    "error",
-    { "allowConfig": true }
-  ]
-}
-```
-
-## When Not To Use It
-
-If you are confident that `shareReplay` is used properly your project,
-then you may not need this rule.
-However, keep in mind that it's recommended to always provide a config object
-that explicitly specifies `refCount` (see linked blog post);
-by default, `shareReplay` without any config defaults to `refCount: false`,
-which means the source observable will never be unsubscribed from,
-potentially leading to unexpected behavior and memory leaks.
-
-## Further reading
-
-- [What's changed with shareReplay](https://ncjamieson.com/whats-changed-with-sharereplay/)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-sharereplay.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-sharereplay.test.ts)

package/docs/rules/no-subclass.md

@@ -1,23 +0,0 @@
-# Disallow subclassing RxJS classes (`rxjs-x/no-subclass`)
-
-💼 This rule is enabled in the 🔒 `strict` config.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-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.
-
-## When Not To Use It
-
-If you need to subclass RxJS classes in your project, then don't use this rule.
-However, keep in mind that implementation details may change in the future;
-You might consider using ESLint disable comments for specific situations
-instead of completely disabling this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subclass.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subclass.test.ts)

package/docs/rules/no-subject-unsubscribe.md

@@ -1,63 +0,0 @@
-# Disallow calling the `unsubscribe` method of subjects (`rxjs-x/no-subject-unsubscribe`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if the `unsubscribe` method is called on subjects.
-The method behaves differently to the `unsubscribe` method on subscriptions and is often an error.
-
-This rule also effects failures if a subject is passed to a subscription's `add` method.
-Adding a subject to a subscription will cause the subject's `unsubscribe` method to get called
-when the subscription is unsubscribed.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { Subject } from "rxjs";
-
-const subject = new Subject<number>();
-subject.unsubscribe();
-```
-
-```ts
-import { Subject, Subscription } from "rxjs";
-
-const subject = new Subject<number>();
-const subscription = new Subscription();
-subscription.add(subject);
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { Subject } from "rxjs";
-
-const subject = new Subject<number>();
-subject.complete();
-```
-
-## When Not To Use It
-
-If you intentionally use `unsubscribe` to cause errors when subjects are `next`-ed after closing,
-then you don't need this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Further reading
-
-- [Closed Subjects](https://ncjamieson.com/closed-subjects/)
-- [Composing Subscription](https://ncjamieson.com/composing-subscriptions/)
-
-## Related To
-
-- [`no-redundant-notify`](./no-redundant-notify.md)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subject-unsubscribe.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subject-unsubscribe.test.ts)

package/docs/rules/no-subject-value.md

@@ -1,19 +0,0 @@
-# Disallow accessing the `value` property of a `BehaviorSubject` instance (`rxjs-x/no-subject-value`)
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects an error if the `value` property - or `getValue` method - of a `BehaviorSubject` is used.
-
-## When Not To Use It
-
-If your code uses the `value` property or the `getValue` method of `BehaviorSubject`,
-then don't enable this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subject-value.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subject-value.test.ts)

package/docs/rules/no-subscribe-handlers.md

@@ -1,53 +0,0 @@
-# Disallow passing handlers to `subscribe` (`rxjs-x/no-subscribe-handlers`)
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures whenever `subscribe` is called with handlers.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { of } from "rxjs";
-import { tap } from "rxjs/operators";
-
-of(42, 54).subscribe((value) => console.log(value));
-```
-
-```ts
-import { of } from "rxjs";
-import { tap } from "rxjs/operators";
-
-of(42, 54).subscribe({
-  next: (value) => console.log(value),
-});
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { of } from "rxjs";
-
-of(42, 54)
-  .pipe(tap((value) => console.log(value)))
-  .subscribe();
-```
-
-## When Not To Use It
-
-If you don't require all logic to go in the `pipe` section of your observables, then you don't need this rule.
-Also, if your project uses `no-ignored-subscribe`, which is the opposite of this rule, then you should not use this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Related To
-
-- [`no-ignored-subscribe`](./no-ignored-subscribe.md)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subscribe-handlers.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subscribe-handlers.test.ts)

package/docs/rules/no-subscribe-in-pipe.md

@@ -1,55 +0,0 @@
-# Disallow calling of `subscribe` within any RxJS operator inside a `pipe` (`rxjs-x/no-subscribe-in-pipe`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if `subscribe` is called within any operator inside a `pipe` operation.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-import { of } from "rxjs";
-import { map } from "rxjs/operators";
-
-of(42, 54).pipe(
-  map(value => {
-    of(value).subscribe(console.log);
-    return value * 2;
-  })
-).subscribe(result => console.log(result));
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-import { of } from "rxjs";
-import { map, tap } from "rxjs/operators";
-
-of(42, 54).pipe(
-  tap(value => console.log(value)),
-  map(value => value * 2)
-).subscribe(result => console.log(result));
-```
-
-## When Not To Use It
-
-If you need to subscribe within `pipe` and are aware of the potential issues,
-then you might not need this rule.
-However, you should typically prefer to use higher-order mapping operators
-like `mergeMap`, `switchMap`, or `concatMap` to handle nested observables.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Related To
-
-- [`no-nested-subscribe`](./no-nested-subscribe.md)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-subscribe-in-pipe.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-subscribe-in-pipe.test.ts)

package/docs/rules/no-tap.md

@@ -1,7 +0,0 @@
-# Disallow the `tap` operator (`rxjs-x/no-tap`)
-
-❌ This rule is deprecated. It was replaced by [`rxjs-x/ban-operators`](ban-operators.md).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if the `tap` operator is used.

package/docs/rules/no-topromise.md

@@ -1,32 +0,0 @@
-# Disallow use of the `toPromise` method (`rxjs-x/no-topromise`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💡 This rule is manually fixable by [editor suggestions](https://eslint.org/docs/latest/use/core-concepts#rule-suggestions).
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if the `toPromise` method is used.
-
-This rule provides two editor suggestions which replace `toPromise` with either:
-
-- `lastValueFrom(...)`, which behaves closest to the behavior of `toPromise`,
-- or `firstValueFrom(...)`.
-
-## When Not To Use It
-
-If you rely on RxJS's deprecation of `toPromise` and don't need to double-flag usage,
-then you don't need this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Further reading
-
-- [Conversion to Promises](https://rxjs.dev/deprecations/to-promise)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-topromise.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-topromise.test.ts)

package/docs/rules/no-unbound-methods.md

@@ -1,61 +0,0 @@
-# Disallow passing unbound methods (`rxjs-x/no-unbound-methods`)
-
-💼 This rule is enabled in the following configs: ✅ `recommended`, 🔒 `strict`.
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if unbound methods are passed as callbacks.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-return this.http
-  .get<Something>("https://api.some.com/things/1")
-  .pipe(
-    map(this.extractSomeProperty),
-    catchError(this.handleError)
-  );
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-return this.http
-  .get<Something>("https://api.some.com/things/1")
-  .pipe(
-    map((s) => this.extractSomeProperty(s)),
-    catchError((e) => this.handleError(e))
-  );
-```
-
-```ts
-return this.http
-  .get<Something>("https://api.some.com/things/1")
-  .pipe(
-    map(this.extractSomeProperty.bind(this)),
-    catchError(this.handleError.bind(this))
-  );
-```
-
-## When Not To Use It
-
-If every handler in your project does not depend on the `this` context in their implementations,
-then in some cases it may be safe to not use this rule.
-However, keep in mind that future changes may introduce bugs
-by changing their implementations to depend on the `this` context;
-see the linked blog post for best practice explanation.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Further reading
-
-- [Avoiding unbound methods](https://ncjamieson.com/avoiding-unbound-methods/)
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unbound-methods.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unbound-methods.test.ts)

package/docs/rules/no-unsafe-catch.md

@@ -1,74 +0,0 @@
-# Disallow unsafe `catchError` usage in effects and epics (`rxjs-x/no-unsafe-catch`)
-
-💭 This rule requires [type information](https://typescript-eslint.io/linting/typed-linting).
-
-<!-- end auto-generated rule header -->
-
-This rule effects failures if `catchError` is used in an effect or epic in a manner that will complete the outermost observable.
-
-## Rule details
-
-Examples of **incorrect** code for this rule:
-
-```ts
-actions.pipe(
-  ofType("SOMETHING"),
-  switchMap((action) => something(action)),
-  catchError(handleError)
-);
-```
-
-Examples of **correct** code for this rule:
-
-```ts
-actions.pipe(
-  ofType("SOMETHING"),
-  switchMap((action) => something(action).pipe(
-    catchError(handleError)
-  ))
-);
-```
-
-```ts
-actions.pipe(
-  ofType("SOMETHING"),
-  switchMap((action) => something(action)),
-  catchError((error, caught) => {
-    handleError(error);
-    return caught;
-  })
-);
-```
-
-## Options
-
-<!-- begin auto-generated rule options list -->
-
-| Name         | Description                                                   | Type   | Default                  |
-| :----------- | :------------------------------------------------------------ | :----- | :----------------------- |
-| `observable` | A RegExp that matches an effect or epic's actions observable. | String | `[Aa]ction(s\|s\$\|\$)$` |
-
-<!-- end auto-generated rule options list -->
-
-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.
-
-```json
-{
-  "rxjs-x/no-unsafe-catch": [
-    "error",
-    { "observable": "[Aa]ction(s|s\\$|\\$)$" }
-  ]
-}
-```
-
-## When Not To Use It
-
-If you don't use a library with effects and epics (e.g. NgRx or redux-observable),
-then you don't need this rule.
-
-Type checked lint rules are more powerful than traditional lint rules, but also require configuring type checked linting.
-
-## Resources
-
-- [Rule source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/src/rules/no-unsafe-catch.ts)
-- [Test source](https://github.com/JasonWeinzierl/eslint-plugin-rxjs-x/blob/main/tests/rules/no-unsafe-catch.test.ts)