chore: Add oxlint plugin to warn about TS-private class members - #4035
Conversation
janbuchar
added
adhoc
| { name: 'field', code: 'class A { private a = 1; }', errors: [{ messageId: 'preferHash' }] }, | ||
| { name: 'static field', code: 'class A { private static a = 1; }', errors: [{ messageId: 'preferHash' }] }, | ||
| { name: 'readonly field', code: 'class A { private readonly a = 1; }', errors: [{ messageId: 'preferHash' }] }, | ||
| { name: 'method', code: 'class A { private a() {} }', errors: [{ messageId: 'preferHash' }] }, |
There was a problem hiding this comment.
IIRC my PR left methods with TS private, so I am puzzled this is not screaming already
up to you if you really want to enforce those, no strong opinions.
There was a problem hiding this comment.
Oh, it produces warnings, not errors, now I get it. Honestly, I hate linter warnings, they just get ignored. If we care about this, I'd make it a hard error.
There was a problem hiding this comment.
Honestly, I hate linter warnings, they just get ignored
Me too, but this should at least make coding assistants stop generating ts-private fields. We should make the rule an error after the existing issues are fixed.
There was a problem hiding this comment.
it's just 10 of them, i'd fix them as part of this PR, but up to you...
|
Second thought - shall we (eventually) enable the Once we fix the current warnings, it might be useful as a "regression" test. |
|
I believe that's already the case, oxlint does that by default. |
|
Indeed, you wouldn't get this on top of the logs without the github output format. 
|
4 participants
It's a warning for now