Changes to the recommended sets for 5.0.0
#3746
Comments
bradzacher
added
package: eslint-plugin
|
I would prefer Also consider issues such as #3145 and the rule can be quite annoying. The recommended list should be reserved for rules that are overwhelmingly more useful than annoying, and I dont think this rule makes the cut. |
|
@bradzacher to clarify, this is for |
bradzacher
changed the title
recommended sets for 4.0.0recommended sets for 5.0.0
|
@joealden - ooops, thanks for that. We didn't change the sets in 4.0 so when I copy pasted my old issue from 3.0 I just incremented the version instead of thinking 🤦 @pgsandstrom perhaps we should instead add a new option to ignore function parameters and set it as the default - would that address your concerns with it being recommended? |
|
I think that would improve the rule, but my personal opinion is still that the value it provides is a bit too opinionated and limited to be part of the recommended set. |
|
To put in my 2 cents regarding Regarding a rule that is semi-related to I'm not saying that I think we should 100% remove this rule for the recommended preset, but in my experience, I turn it off most of the time, so I'm wondering what others think regarding this rule. |
+1 to this, I don't think I've ever enabled that rule. |
|
I also always turn off |
|
For me the point of the First - readability. It means you don't have to rely on intellisense to figure out what a function is or does. This makes it easier to do reviews without an IDE. Code is read more times than it's written so IMO optimising for readability is paramount. Second - it allows you to catch problems sooner. In some projects this is fine because you always have a webpack build in watch mode or something, but in others you have no build and must manually run But I understand that some people find it cumbersome. I disagree with it personally, but I understand that some people like to heavily lean on the checker's inference. This is one of the ways in which flow is better than TS (IMO). Flow has a mode called types-first which enables significant performance improvements by only analysing the types of a dependency's exports. For types-first you have to annotate the boundary, and it's a hard compiler error if you don't. But at this point it's pretty clear that this is a divisive topic and nobody agrees on it. Without some perf improvement from TS - it's not worth pushing the style - especially as there are so many people that are against it / turn it off. |
|
@bradzacher This one can be closes as #3809 & #3818 are merged |
Similar to what I did for 3.0.0 (in #1423), I'm putting forward the new recommended set ahead of time.
I'm looking for feedback from the community before we go ahead and make the changes.
Hint: search for the text
(new)to find the changesHeader Key
adjacent‑overload‑signaturesarray‑typeawait‑thenableban‑ts‑commentban‑tslint‑commentban‑typesobjectfrom the default config, because enough people want to use it and disagree with the reasoning.brace‑styleclass‑literal‑property‑stylecomma‑danglecomma‑spacingconsistent‑indexed‑object‑styleconsistent‑type‑assertionsconsistent‑type‑definitionsconsistent‑type‑importsdefault‑param‑lastdot‑notationexplicit‑function‑return‑typeexplicit‑member‑accessibilityexplicit‑module‑boundary‑typesfunc‑call‑spacingindentinit‑declarationskeyword‑spacinglines‑between‑class‑membersmember‑delimiter‑stylemember‑orderingmethod‑signature‑stylenaming‑conventionno‑array‑constructorno‑base‑to‑stringno‑confusing‑non‑null‑assertionno‑confusing‑void‑expressionno‑dupe‑class‑membersno‑duplicate‑importsno‑dynamic‑deleteno‑empty‑functionno‑empty‑interfaceno‑explicit‑anyno‑extra‑non‑null‑assertionno‑extra‑parensno‑extra‑semino‑extraneous‑classno‑floating‑promisesno‑for‑in‑arrayno‑implicit‑any‑catchno‑implied‑evalno‑inferrable‑typesno‑invalid‑thisno‑invalid‑void‑typeno‑loop‑funcno‑loss‑of‑precisionno‑magic‑numbersno‑misused‑newno‑misused‑promisesno‑namespaceno‑non‑null‑asserted‑optional‑chainno‑non‑null‑assertionno‑parameter‑propertiesno‑redeclareeslint-recommendedset.no‑require‑importsno‑shadowno‑this‑aliasno‑throw‑literalno‑type‑aliasno‑unnecessary‑boolean‑literal‑compareno‑unnecessary‑conditionno‑unnecessary‑qualifierno‑unnecessary‑type‑argumentsno‑unnecessary‑type‑assertionno‑unnecessary‑type‑constraintno‑unsafe‑argumentno‑unsafe-*rules.no‑unsafe‑assignmentno‑unsafe‑callno‑unsafe‑member‑accessno‑unsafe‑returnno‑unused‑expressionsno‑unused‑vars‑experimentalno‑unused‑varsnow completely supports TS - so this rule is no longer required.no‑unused‑varsno‑use‑before‑defineno‑useless‑constructorno‑var‑requiresnon‑nullable‑type‑assertion‑styleobject‑curly‑spacingprefer‑as‑constprefer‑enum‑initializersprefer‑for‑ofprefer‑function‑typeprefer‑includesprefer‑literal‑enum‑memberprefer‑namespace‑keywordprefer‑nullish‑coalescingprefer‑optional‑chainprefer‑readonly‑parameter‑typesprefer‑readonlyprefer‑reduce‑type‑parameterprefer‑regexp‑execprefer‑return‑this‑typeprefer‑string‑starts‑ends‑withprefer‑ts‑expect‑errorpromise‑function‑asyncquotesrequire‑array‑sort‑comparerequire‑awaitrestrict‑plus‑operandsrestrict‑template‑expressionsreturn‑awaitsemisort‑type‑union‑intersection‑membersspace‑before‑function‑parenspace‑infix‑opsstrict‑boolean‑expressionsswitch‑exhaustiveness‑checktriple‑slash‑referencetype‑annotation‑spacingtypedefunbound‑methodunified‑signaturesThe text was updated successfully, but these errors were encountered: