You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add the required rule prefix @typescript-eslint/ before the rule name for it to actually have the intended effect.
Let's deactivate @typescript-eslint/lines-between-class-members (Expected blank line between class members) which afaict was added as part of a large set of rules and wasn't discussed specifically.
Very frequently, class members have a number of properties. They generally take up a single line. Forcing developers to add a line, automatically or not, yields objectionable, verbose code. It adds separation and heft where it often shouldn't. While beauty is in the eye of the beholder. as it's a subjective matter, let's retain the freedom - anyone can still add a line manually, but if the rule is active, it's impossible not to have a filler line.
Also, this is not a proposal to prohibit line drops.
For what it's worth, I also don't think it'd be good to enforce a line drop between adjacent top-level definitions in a file. For example, it'd enforce short constant assignments and maybe imports to be separated by a line drop
The text was updated successfully, but these errors were encountered:
Add the required rule prefix
@typescript-eslint/
before the rule name for it to actually have the intended effect.Let's deactivate@typescript-eslint/lines-between-class-members
(Expected blank line between class members) which afaict was added as part of a large set of rules and wasn't discussed specifically.Very frequently, class members have a number of properties. They generally take up a single line. Forcing developers to add a line, automatically or not, yields objectionable, verbose code. It adds separation and heft where it often shouldn't. While beauty is in the eye of the beholder. as it's a subjective matter, let's retain the freedom - anyone can still add a line manually, but if the rule is active, it's impossible not to have a filler line.Also, this is not a proposal to prohibit line drops.For what it's worth, I also don't think it'd be good to enforce a line drop between adjacent top-level definitions in a file. For example, it'd enforce short constant assignments and maybe imports to be separated by a line dropThe text was updated successfully, but these errors were encountered: