Open jpzwarte opened 1 year ago
if i understand correctly, this is because if you do:
html`
${this.someMethod}
`;
unbound-method
in tseslint will trigger since it wants us to pass () => this.someMethod()
or this.someMethod.bind(this)
?
i do wonder if we'll be forever playing catch up with that rule since it conflicts directly with how lit code is written. maybe we should just recommend turning the tseslint rule off?
unbound-method
in tseslint will trigger since it wants us to pass() => this.someMethod()
orthis.someMethod.bind(this)
?
Correct. The jest plugin I link to disables it where it does make sense in the context of jest.
i do wonder if we'll be forever playing catch up with that rule since it conflicts directly with how lit code is written. maybe we should just recommend turning the tseslint rule off?
I think it only conflicts with code inside templates, right? Outside of templates, it is a perfectly valid rule?
what i mean is the no-template-arrow
rule is stylistic really - pushing people to move functions into methods or variables instead of inlining them
i think we should just remove it from the recommended rule set and users of tseslint's recommended config would just not enable it (no-template-arrow
).
anyone who does want to enable it should probably disable unbound-method
too since the two usages will always conflict.
This is similar to https://github.com/jest-community/eslint-plugin-jest/blob/main/src/rules/unbound-method.ts
The jest plugin checks whether the unbound method is valid in the context of jest, or it falls back to the typescript-eslint/unbound-method rule.
It would be helpful if the
lit/no-template-arrow
rule did the same. Especially now that the latesteslint-config-standard-with-typescript
version now includes the@typescript-eslint/unbound-method
rule.