Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-43672

eslint rules are aggressively stupid

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      Blue Ocean - 1.1-beta-1, Blue Ocean - 1.1-beta2, Blue Ocean 1.1-beta4, Blue Ocean 1.1

      Description

      Eslint rules are aggressively stupid and shout at crappy things like line length rules or space before braces rules that no one cares about.

      Please review and relax some of these rules so that frontend developers don't spend 20% of time fixing eslint errors.

        Attachments

          Activity

          Hide
          jamesdumay James Dumay added a comment -

          Michael Neale said you have been crowed eslint rules czar so make the changes that you want and beg for forgiveness.

          Show
          jamesdumay James Dumay added a comment - Michael Neale said you have been crowed eslint rules czar so make the changes that you want and beg for forgiveness.
          Hide
          cliffmeyers Cliff Meyers added a comment -

          I would go so far as to say we should look at removing es-lint entirely and tend toward something like Prettier:

          https://github.com/prettier/prettier

          I'd want to float that by the team before taking it on, but it should completely eliminate the need fix violations since it's a formatter rather than a linter.

          Show
          cliffmeyers Cliff Meyers added a comment - I would go so far as to say we should look at removing es-lint entirely and tend toward something like Prettier: https://github.com/prettier/prettier I'd want to float that by the team before taking it on, but it should completely eliminate the need fix violations since it's a formatter rather than a linter.
          Hide
          jamesdumay James Dumay added a comment - - edited

          Cliff Meyers I was thinking about this last night - we don't have any code style rules in the Java code. Apart from making things look pretty, jslint used to basically do a bunch of checking around javascript compatibility across browsers (some liked trailing ';' and some didn't, so a lint rule was created...). Do we need the linter at all if babel is transpiling and checking stuff?

          Show
          jamesdumay James Dumay added a comment - - edited Cliff Meyers I was thinking about this last night - we don't have any code style rules in the Java code. Apart from making things look pretty, jslint used to basically do a bunch of checking around javascript compatibility across browsers (some liked trailing ';' and some didn't, so a lint rule was created...). Do we need the linter at all if babel is transpiling and checking stuff?
          Hide
          cliffmeyers Cliff Meyers added a comment -

          I think formatters provide some value because they can make diffs much easier to read. If every developer on the team codes in their own style, diffs in PR's can be problematic because there are filled with brace changes, extra spaces between params, etc instead of just the functional code changes. Not to say that devs can't still create a lot of "false changes" even with a linter, but at least it's not 'cause curlies are on the same line or a different line.

          Beyond just the formatting, lint does some useful things like suggest use of const instead of let, warn against reassignment of parameters, and some other sensible checks.

          I do this we need to raise the bar significantly in terms of ease of use. Usually formatters are run as a pre-commit hook (or even on file save when IDE support is there). If we landed on either of those would you be receptive to continuing the use of such a tool?

          I think Prettier is fundamentally better since it doesn't check your code for errors, it actually parses it and reformats it every time based on a set of a rules. So as long as your code is valid JS it should be fine, it will just get reformatted for you. So as a pre-commit hook, we shouldn't have to think about it at all. We just need to check to make sure there's some of those values checks in place too. (there is apparently a Prettier project that also supports some limited eslint integration)

          Show
          cliffmeyers Cliff Meyers added a comment - I think formatters provide some value because they can make diffs much easier to read. If every developer on the team codes in their own style, diffs in PR's can be problematic because there are filled with brace changes, extra spaces between params, etc instead of just the functional code changes. Not to say that devs can't still create a lot of "false changes" even with a linter, but at least it's not 'cause curlies are on the same line or a different line. Beyond just the formatting, lint does some useful things like suggest use of const instead of let, warn against reassignment of parameters, and some other sensible checks. I do this we need to raise the bar significantly in terms of ease of use. Usually formatters are run as a pre-commit hook (or even on file save when IDE support is there). If we landed on either of those would you be receptive to continuing the use of such a tool? I think Prettier is fundamentally better since it doesn't check your code for errors, it actually parses it and reformats it every time based on a set of a rules. So as long as your code is valid JS it should be fine, it will just get reformatted for you. So as a pre-commit hook, we shouldn't have to think about it at all. We just need to check to make sure there's some of those values checks in place too. (there is apparently a Prettier project that also supports some limited eslint integration)
          Hide
          cliffmeyers Cliff Meyers added a comment -

          And I'll add that any tool I push must support TypeScript, or have it on the roadmap.

          Show
          cliffmeyers Cliff Meyers added a comment - And I'll add that any tool I push must support TypeScript, or have it on the roadmap.
          Hide
          jamesdumay James Dumay added a comment -

          Cliff Meyers maybe just introduce TypeScript into corejs and see how we go?

          Show
          jamesdumay James Dumay added a comment - Cliff Meyers maybe just introduce TypeScript into corejs and see how we go?

            People

            • Assignee:
              Unassigned
              Reporter:
              jamesdumay James Dumay
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: