-
-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accept concrete (unused) implementations of public abstract methods #360
Comments
How about this: export abstract class AFoo {
public abstract foo(): number
}
export class Foo implements AFoo {
public foo() {
return 0
}
} import { Foo } from "./foo";
const x = new Foo()
function f(x: Foo): number {
return x.foo()
} |
🙈 It indeed seems to work with both |
🤔 I'm still getting it in my large real code, but can't make a MNWE about it. That might be another root cause that my initial analysis… |
Not sure what I can do here. Feel free to close this issue or provide a MNWE. |
Managed to get a MNWE: https://codesandbox.io/p/devbox/mystifying-swanson-ytr3wq The classes |
I still don't see actual usage of the member reported as unused? I see classes, no instances. |
Played a bit more with the MNWE. It seems to be rather linked to
(PS: thank for the tool and the responsiveness to questions 😄, don't take it wrong I love it) |
For now:
|
🚀 This issue has been resolved in v5.3.1. See Release 5.3.1 for release notes. |
I think knip should accept the concrete implementation of an abstract method, even when the concrete version is not used directly, when the abstract method is either
@public
, or used.foo.ts:
index.ts:
When knipping that, I got:
But
Foo#foo
is pretty much needed, and even if functionf
wasn't here, it would be required to implement the abstract method which I've already told knip is meant for external API.Adding a release tag on
Foo#foo
is not really convenient since I have around 40 of these subclasses in my actual case 🙈The text was updated successfully, but these errors were encountered: