Comments (6)
@OliverJAsh ATM, I have little appetite for tweaking this rule, as I didn't write it; I just ported it. I've removed it from the recommended configuration, as I think there are too many exceptions and I don't want to support/explain them.
In the example, E
is only 'used twice' because the return type is a function type in which it's used twice. However, if that function type wasn't inlined, but was something like RxJS's MonoTypeOperatorFunction<T>
, that type itself would have to be found and checked. There is a similar problem with other contextual types too - like in this issue. (And there's a link, IIRC, to the Wotan issue - in the comment above the linked-to comment - which is labelled as "won't fix".)
from eslint-plugin-etc.
I'm not convinced that this is a bug or a false positive.
Rather, I think this is one of the exceptions to the rule. As with operators and pipe
in RxJS - which will also fail this rule - here, the inference is driven via the return type - as what's returned from both
is passed to a function - fnWithCallback
- and it's that function's signature that drives the inference.
If both
is called and the result is assigned to a variable, there is no inference and the usage is not type-safe:
const b = both((name: string) => {}, (age: number) => {}); // (...args: unknown[]) => void
IMO, this is an example of a situation in which the rule is inappropriate and I don't see how the rule could cope with these situations - given that the declaration and the call sites are separated, so to speak.
Thoughts?
from eslint-plugin-etc.
One option could be a specific failure message that states that inference is only possible via the return value.
from eslint-plugin-etc.
That's a good point @cartant. The error would have to be at the call site, not the definition. Or perhaps this is just a case where disabling the linter for that line makes sense.
from eslint-plugin-etc.
As with operators and
pipe
in RxJS
Yes, I'm running into this a lot with operators. Not just for RxJS but all the types in fp-ts.
Reduced test case:
const fn = <E>() => (e: E): E => e;
Maybe this lint rule should only be concerned with the definition, not the call site (we could have a separate lint rule for that). In that case, this lint rule would determine this is a safe definition, because the generic is used in two positions: a parameter and the return type.
from eslint-plugin-etc.
3+ years later, I see that my both
function can easily be rewritten to not break this rule:
export function both<Args extends unknown[]>(
fn1: (...args: Args) => void,
fn2: (...args: Args) => void,
): (...args: Args) => void {
return function (...args: Args) {
fn1(...args);
fn2(...args);
};
}
Maybe TypeScript has gotten smarter since 2020? Or maybe this was just working as intended all along!
from eslint-plugin-etc.
Related Issues (20)
- Feature request: Add option to avoid conflict with @typescript-eslint/prefer-function-type rule
- Feature request: prefer-type
- etc/no-deprecated: support detection within `exports`
- [etc/prefer-interface]: Does not report constructor signature
- `etc/prefer-interface` conflicts with `@typescript-eslint/prefer-function-type` HOT 1
- It seems much similar to `eslint-plugin-sonar` and `eslint-plugin-unicorn`
- `etc/throw-error` crash when rejecting with no value
- `no-commented-out-code` thinks that `// TODO: SOME-TICKET-NR-123` is code
- no-commented-out-code can't detect the chinese comment HOT 1
- `prefer-interface` rule fixer causes compilation error". An interface can only extend an object type or intersection of object types with statically known members"
- no-internal: Ignore internals defined in the same file
- TypeScript 5 support HOT 4
- Is there a way to set no-commented-out-code HOT 1
- Upgrade eslint-etc to v5.2.1
- TypeError: Cannot read properties of undefined (reading 'parent') HOT 2
- Cannot read properties of undefined 'typeAnnotation'
- Library is broken with Typescript v5.2 HOT 12
- Specify what rules are compatible with Javascript and what ones can only work with Typescript
- [Feature request] `prefer-readonly-array`
- [no-assign-mutated-array] doesn't account for `flatMap`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eslint-plugin-etc.