feat(no-ignored-default-value): allow to configure ignored methods/sources

[SchroederSteffen]

In our project using NestJS, we call methods that return observables which will definitely have a value.
Example: https://github.com/nestjs/axios/blob/5299e053ab61f9f9c9b3cb3f75d822133c91c9df/lib/http.service.ts#L143-L144
There are surely also other similar cases.

We would like to keep the rule no-ignored-default-value enabled to catch custom observables while also avoid having to disable it for every safe usage.
To achieve this, we would like to configure a set of allowed methods that should be ignored by this rule.

I'm not sure how to achieve this best without risking false negatives, maybe using regex patterns.
The rule eslint-plugin-jest/expect-expect does something similar: https://github.com/jest-community/eslint-plugin-jest/blob/main/docs/rules/expect-expect.md#assertfunctionnames

[JasonWeinzierl]

Hmm. Off the top of my head, this seems very difficult and/or risks lots of false negatives, as you observe.

For example, if your allowlist was ['get', 'post', 'put', 'delete'], then any function in your codebase with a function named get etc. would be ignored by this rule, even if it's not HttpService.get. e.g. MyOtherService.get() wouldn't get checked. The Jest expect-expect rule is likely able to get away with it because: (1) they're restricted to just unit test files, and (2) expect is a fairly unique behavior/function name that is unlikely to appear elsewhere in the codebase.

Perhaps we could specify classes which always return good observables e.g. ['HttpService'] but the type-checking required to detect that might perform very poorly...

---

(Take my opinion with a grain of salt as I've never used NestJS, but:) Do you really need RxJS for your use-case at all? axios is a Promise-based library in the first place. The linked NestJS-axios plugin converts it to RxJS, but then... are you converting it back to a Promise with lastValueFrom, etc.? Would it be better to just use axios directly?

[SchroederSteffen]

Thanks for the response.

Hmm. Off the top of my head, this seems very difficult and/or risks lots of false negatives, as you observe.
[...]
Perhaps we could specify classes which always return good observables e.g. ['HttpService'] but the type-checking required to detect that might perform very poorly...

I agree that a list of method names is not enough. The class name must be checked, too.
Unfortunately, I'm not experienced in writing ESLint rules myself.

(Take my opinion with a grain of salt as I've never used NestJS, but:) Do you really need RxJS for your use-case at all? axios is a Promise-based library in the first place. The linked NestJS-axios plugin converts it to RxJS, but then... are you converting it back to a Promise with lastValueFrom, etc.? Would it be better to just use axios directly?

I think NestJS provides Observables because you may want to include the requests in a more sophisticated pipe. We also do that in some projects, e.g. when we send multiple requests.
But in more simple projects, we don't use RxJs very much and we prefer using Promises to improve the code readability.

In our shared configuration used in simple AND complex projects, we would like to configure a generic allow list.

Personally, I would prefer if NestJS would expose Promises. Consumers can still convert them into Observables themselves. However, they don't seem to plan to do that based on the Q&As I found.
We also use Angular which also exposes Observables: https://angular.dev/api/common/http/HttpClient (and NestJS is inspired by Angular)

[SchroederSteffen]

Related: ReactiveX/rxjs#5273