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
{{ message }}
This repository has been archived by the owner on Jul 15, 2023. It is now read-only.
Like I mentioned before, we use and love this package and recommended ruleset, and I know we'll contribute more to it in the coming months.
One rule we dislike is newline-before-return. We think it does not bring any value (as opposed to padding blocks overall, which ESLint allows but not TSLint), and it even ends up in silly situations when you try to leverage FP-style methods (.map, etc.), for example:
On top of this, this rule is not auto-fixable, so it cannot be fixed by an editor or a pre-commit hook (which we found sound for style-related rules).
Besides, we use Prettier for consistent styling which is an amazing tool, and we hope that they will someday include newline consistency in their formatting (it's only partially supported at the moment because it's technically difficult but they keep improving it at an impressive pace so who knows).
Would you be willing to disable this rule in the recommended ruleset?
The text was updated successfully, but these errors were encountered:
If you want to make some improvements on the TSLint side, it'd be great if you could file issues there & link them back here. Eventually it seems reasonable to re-enable the rule once the flaws you mentioned are fixed.
Hi there!
Like I mentioned before, we use and love this package and recommended ruleset, and I know we'll contribute more to it in the coming months.
One rule we dislike is
newline-before-return
. We think it does not bring any value (as opposed to padding blocks overall, which ESLint allows but not TSLint), and it even ends up in silly situations when you try to leverage FP-style methods (.map
, etc.), for example:In fact, I noticed that this repo itself calls it "kind of a silly rule" 😁
On top of this, this rule is not auto-fixable, so it cannot be fixed by an editor or a pre-commit hook (which we found sound for style-related rules).
Besides, we use Prettier for consistent styling which is an amazing tool, and we hope that they will someday include newline consistency in their formatting (it's only partially supported at the moment because it's technically difficult but they keep improving it at an impressive pace so who knows).
Would you be willing to disable this rule in the recommended ruleset?
The text was updated successfully, but these errors were encountered: