9 ms·

ESLint 7.0

205 points by himynameisdave 6y ago

tuukkah 6y ago
I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments https://eslint.org/docs/user-guide/configuring#disabling-rul...
- mikewhy 6y ago
  How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello');
  - httgp 6y ago
    You could be commenting functions too (day JSDoc it TSDoc) but also want to do an eslint-ignore. It looks better then, IMO.
  - jrrrr 6y ago
    Well, it's on one line for starters ;) Looking at one suppression in one place it doesn't make a big difference. It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.
  - tuukkah 6y ago
    In short: it's more comfortable and more versatile. 1. Sometimes there's already a comment on the preceding line commenting the logic, and the new comment explaining ESLint would have to go awkwardly in-between. 2. Sometimes it's just complicated to word the comment if it can't be on the same line. 3. Sometimes eslint-disable-line is in a place where it would be ugly to have a comment above. Here are two examples from my current project, both from cases where the disable is right after a closing curly brace: } as any // eslint-disable-line @typescript-eslint/no-explicit-any }, [map]); // eslint-disable-line react-hooks/exhaustive-deps Other cases can be found in the issues: Feature request #1: https://github.com/eslint/eslint/issues/11298 https://github.com/eslint/eslint/issues/11298 Feature request #2: https://github.com/eslint/eslint/issues/11806 https://github.com/eslint/eslint/issues/11806 RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-description-in-directive-comments https://github.com/eslint/rfcs/tree/master/designs/2019-desc... Next up: an ESLint rule that makes the comment obligatory for disable directives.
- shpx 6y ago
  Yo dawg, heard you like comments
baggachipz 6y ago
Ah ESLint, the most necessary bane of my existence. Good work to the team for the update.
- PretzelFisch 6y ago
  I just could not deal with such an opinionated tool. ESLint would not let us adjust settings to accept some of our normal convection's and company code style guidelines. I switched to jshint and have lived a much happier life.
  - jakub_g 6y ago
    That's interesting, given that the original idea behind eslint was to create a tool to fix the warts of jshint which was apparently not enough flexible! https://eslint.org/docs/about/ https://eslint.org/docs/about/ > The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable. > Every rule... Can be turned off or on (nothing can be deemed "too important to turn off") > Rules are "agenda free" - ESLint does not promote any particular coding style Is it the eslint that's opinionated, of the rules config that you were using? Or the maintainers of the rules in the github repo? (or is this sarcasm :)
    - PretzelFisch 6y ago
      Sorry this was me mixing up JSLint and ESLint
      - jakub_g 6y ago
        Ah, gotcha. JSHint was indeed created to fix JSLint's even greater non-flexibility, long time ago.
  - yepthatsreality 6y ago
    I feel this way but about `prettier.js` (as opposed to eslint.js) instead.
haolez 6y ago
I didn't like programming in JavaScript so much because I think the syntax makes it a little harder to read than necessary. However, I confess that after adopting ESLint in my workflow, things have improved considerably. I can ask it to warn me on unused stuff, to enforce the lack of semicolons, to format and indent my code correctly on save... it's a very useful tool. If you have something against JavaScript in general, give it a try.
- Bishonen88 6y ago
  You can do most of that without ESLint for any programming language with an IDE. Speaking about jetbrains intellij/pycharm from my own experience.
  - haolez 6y ago
    The IDEs will sometimes use their in-house solution, and sometimes integrate one of these external tools that focus on doing just one thing very well. My setup is VSCode + ESLint when dealing with JavaScript.
  - Kaze404 6y ago
    The point of these tools is that the configuration is specified in the project, and works regardless of the developer's workflow.
    - deleted 6y ago
      [deleted]
- vorpalhex 6y ago
  I also recommend `prettier`. It can be configured to obey eslint and will reformat your code on the fly to fit standards so you can spend less time fighting spacing and more time just writing code. While `eslint --fix` is a thing, prettier parses the underlying AST to do it's transformations and it's a very impressive tool.
  - 6y ago
kbd 6y ago
I haven't done TypeScript/JavaScript in a while. What's the status of ESLint taking over from TSLint (for both the tool itself and the vscode extensions)?
- azemetre 6y ago
  I think the transition is nearly ironed out, I'd say the only concerns are the edge cases but everyday usage should be fine: https://github.com/typescript-eslint/typescript-eslint https://github.com/typescript-eslint/typescript-eslint Haven't ran into too many issues within the last 8 months or so. Only in Spring 2019 was it bad IME.
- deleted 6y ago
  [deleted]
- nikaspran 6y ago
  Have exclusively used ESLint for TypeScript over the past year. It works great, no issues. The only slight problem is some rules conflict, but that only comes into play if using a comprehensive preset like airbnb.
aaomidi 6y ago
There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule. So many bugs in the JS world is because of dangling promises.
- ausjke 6y ago
  hundreds of rules to read, is this on its recommended list if it's so critical? is its name 'no-floating-promises'?
  - williamdclt 6y ago
    > is its name 'no-floating-promises' Yes, and I subscribe to the parent's sentiment: this rule is essential
    - brycelarkin 6y ago
      https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/...
  - aaomidi 6y ago
    It's unfortunately not on the recommended list. For very few circumstances the rule doesn't make sense, but most of the time that shows bad programming design. That's the name!
  - johnsoft 6y ago
    >is this on its recommended list Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change. https://github.com/typescript-eslint/typescript-eslint/issues/1423 https://github.com/typescript-eslint/typescript-eslint/issue...
  - aaomidi 6y ago
    I also highly recommend just reading all the rules if you're a JS/TS developer. It really helps you see what stuff could be very useful.
huy-nguyen 6y ago
Does this release support Yarn v2’s Plug’n’Play?
moltar 6y ago
Sad to see that bundled packages with shareable config are still not supported :(
sadturnip 6y ago
Does anyone know if they have addressed the major performance problems with typescript? This was a few months ago, but tslint takes a few seconds on one of our larger code bases. However ESLint with the typescript plugin would take up to a minute+, and seemed to make webstorm struggle with the eslint integration.
- DerJacques 6y ago
  Could it be that you were using type-aware linting rules? If you have these rules enabled, ESLint basically has to compile all your TS files to check if the rules are followed. Note that most of the ESLint rules are _not_ type aware, but following the setup guides quickly has you turning them on “by accident”. For more details, see: https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/TYPED_LINTING.md https://github.com/typescript-eslint/typescript-eslint/blob/...
- root_axis 6y ago
  Been testing it out the beta, in my experience performance is better but still behind tslint, though tslint lacks a ton of rules compared to eslint so I am guessing that is partially why. I think the webstorm struggle is a webstorm specific issue, I've seen a few of my co-workers experience similar webstorm slow downs from eslint (and ts) but it works fine for me in vim without any slowdown of the editor itself.
- dfee 6y ago
  You’ll probably need to be more specific about the speed issues you’re seeing. I don’t see that issue, but I also factor my code into smaller packages in my monorepo (which is a good practice). I still have relatively long lint times against the monorepo (greater than a minute), but that’s part of the CI stage.
tobilg 6y ago
Hopefully it got a little less „dependency-heavy“ than before. Using eslint and babel tends to add 200mb of dev dependencies to a project...
- Kaze404 6y ago
  ~ λ mkdir -p /tmp/js ~ λ cd /tmp/js /tmp/js λ npm init -y & npm i eslint babel [snip] /tmp/js λ du -h node_modules [snip] 36M node_modules
  - tobilg 6y ago
    While this might be correct, in the a lot of cases you'll also use a lot of plugins for both to enable the desired transpilations and checks... I should have been more precise in my first comment though.
dwrodri 6y ago
I know the whole "there are two types of programming languages" Stroustrup quote applies to JS just as much as it does to C++, but can anyone comment on whether JS was hated as much as it was back when this second generation of browsers was being built? As someone who went straight into research and low-level work, I don't touch JS very often, but it seems to me as though the Web is in this arranged marriage it doesn't like, but refuses to leave because of the inconvenience. I feel like in some regards, we have seen generational shifts in other languages. In domains where Perl, Java, and C++ used to dominate, we now have Go, Rust, and Python. Absolutely worth noting that with the exception of Python, there are probably still vastly more lines of C++/Java code running in production than Go/Rust. I kind of don't get how if JavaScript is so bad, then why do we now have things like Node?
- Latty 6y ago
  If I had to guess, I'd say Node is popular because the web has eaten the world, and if you already have a web app as the core of your development, it starts to make sense to make everything else just an extension of that, including your server so you can do things like server-side rendering. A lot of that development seems to be TypeScript too, which helps mitigate a lot of the problems of raw JavaScript, and the structural typing makes working with JSON (something now pretty universal too) far easier than with a lot of languages. There are a lot of things I hate about JavaScript itself, but TypeScript's type system is genuinely great.

I have been waiting for this release for the new possibility to include a comment in eslint-disable-{next-}line: // eslint-disable-next-line no-console -- Here's a description about why this configuration is necessary. console.log('hello'); https://eslint.org/docs/user-guide/configuring#disabling-rules-with-inline-comments https://eslint.org/docs/user-guide/configuring#disabling-rul...

mikewhy 6y ago
How is that different than: // Here's a description about why this configuration is necessary. // eslint-disable-next-line no-console console.log('hello');
- httgp 6y ago
  You could be commenting functions too (day JSDoc it TSDoc) but also want to do an eslint-ignore. It looks better then, IMO.
- jrrrr 6y ago
  Well, it's on one line for starters ;) Looking at one suppression in one place it doesn't make a big difference. It will help a lot with whole-project search results, though, if you're trying to e.g. fix all the places you had to suppress X because of Y.
- tuukkah 6y ago
  In short: it's more comfortable and more versatile. 1. Sometimes there's already a comment on the preceding line commenting the logic, and the new comment explaining ESLint would have to go awkwardly in-between. 2. Sometimes it's just complicated to word the comment if it can't be on the same line. 3. Sometimes eslint-disable-line is in a place where it would be ugly to have a comment above. Here are two examples from my current project, both from cases where the disable is right after a closing curly brace: } as any // eslint-disable-line @typescript-eslint/no-explicit-any }, [map]); // eslint-disable-line react-hooks/exhaustive-deps Other cases can be found in the issues: Feature request #1: https://github.com/eslint/eslint/issues/11298 https://github.com/eslint/eslint/issues/11298 Feature request #2: https://github.com/eslint/eslint/issues/11806 https://github.com/eslint/eslint/issues/11806 RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-description-in-directive-comments https://github.com/eslint/rfcs/tree/master/designs/2019-desc... Next up: an ESLint rule that makes the comment obligatory for disable directives.
shpx 6y ago
Yo dawg, heard you like comments

baggachipz 6y ago

Ah ESLint, the most necessary bane of my existence. Good work to the team for the update.

PretzelFisch 6y ago
I just could not deal with such an opinionated tool. ESLint would not let us adjust settings to accept some of our normal convection's and company code style guidelines. I switched to jshint and have lived a much happier life.
- jakub_g 6y ago
  That's interesting, given that the original idea behind eslint was to create a tool to fix the warts of jshint which was apparently not enough flexible! https://eslint.org/docs/about/ https://eslint.org/docs/about/ > The primary reason ESLint was created was to allow developers to create their own linting rules. ESLint is designed to have all rules completely pluggable. > Every rule... Can be turned off or on (nothing can be deemed "too important to turn off") > Rules are "agenda free" - ESLint does not promote any particular coding style Is it the eslint that's opinionated, of the rules config that you were using? Or the maintainers of the rules in the github repo? (or is this sarcasm :)
  - PretzelFisch 6y ago
    Sorry this was me mixing up JSLint and ESLint
    - jakub_g 6y ago
      Ah, gotcha. JSHint was indeed created to fix JSLint's even greater non-flexibility, long time ago.
- yepthatsreality 6y ago
  I feel this way but about `prettier.js` (as opposed to eslint.js) instead.

haolez 6y ago

I didn't like programming in JavaScript so much because I think the syntax makes it a little harder to read than necessary. However, I confess that after adopting ESLint in my workflow, things have improved considerably. I can ask it to warn me on unused stuff, to enforce the lack of semicolons, to format and indent my code correctly on save... it's a very useful tool. If you have something against JavaScript in general, give it a try.

Bishonen88 6y ago
You can do most of that without ESLint for any programming language with an IDE. Speaking about jetbrains intellij/pycharm from my own experience.
- haolez 6y ago
  The IDEs will sometimes use their in-house solution, and sometimes integrate one of these external tools that focus on doing just one thing very well. My setup is VSCode + ESLint when dealing with JavaScript.
- Kaze404 6y ago
  The point of these tools is that the configuration is specified in the project, and works regardless of the developer's workflow.
  - deleted 6y ago
    [deleted]
vorpalhex 6y ago
I also recommend `prettier`. It can be configured to obey eslint and will reformat your code on the fly to fit standards so you can spend less time fighting spacing and more time just writing code. While `eslint --fix` is a thing, prettier parses the underlying AST to do it's transformations and it's a very impressive tool.
- 6y ago

kbd 6y ago

I haven't done TypeScript/JavaScript in a while. What's the status of ESLint taking over from TSLint (for both the tool itself and the vscode extensions)?

azemetre 6y ago
I think the transition is nearly ironed out, I'd say the only concerns are the edge cases but everyday usage should be fine: https://github.com/typescript-eslint/typescript-eslint https://github.com/typescript-eslint/typescript-eslint Haven't ran into too many issues within the last 8 months or so. Only in Spring 2019 was it bad IME.
deleted 6y ago
[deleted]
nikaspran 6y ago
Have exclusively used ESLint for TypeScript over the past year. It works great, no issues. The only slight problem is some rules conflict, but that only comes into play if using a comprehensive preset like airbnb.

aaomidi 6y ago

There is a rule in eslint that warns you when a promise is dangling and hasn't been handled. Please use that rule. So many bugs in the JS world is because of dangling promises.

ausjke 6y ago
hundreds of rules to read, is this on its recommended list if it's so critical? is its name 'no-floating-promises'?
- williamdclt 6y ago
  > is its name 'no-floating-promises' Yes, and I subscribe to the parent's sentiment: this rule is essential
  - brycelarkin 6y ago
    https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md https://github.com/typescript-eslint/typescript-eslint/blob/...
- aaomidi 6y ago
  It's unfortunately not on the recommended list. For very few circumstances the rule doesn't make sense, but most of the time that shows bad programming design. That's the name!
- johnsoft 6y ago
  >is this on its recommended list Not now, but it's planned to be starting with the next major version. They are holding off until then since changing the default rules is considered a breaking change. https://github.com/typescript-eslint/typescript-eslint/issues/1423 https://github.com/typescript-eslint/typescript-eslint/issue...
- aaomidi 6y ago
  I also highly recommend just reading all the rules if you're a JS/TS developer. It really helps you see what stuff could be very useful.

huy-nguyen 6y ago

Does this release support Yarn v2’s Plug’n’Play?

moltar 6y ago

Sad to see that bundled packages with shareable config are still not supported :(

sadturnip 6y ago

Does anyone know if they have addressed the major performance problems with typescript? This was a few months ago, but tslint takes a few seconds on one of our larger code bases. However ESLint with the typescript plugin would take up to a minute+, and seemed to make webstorm struggle with the eslint integration.

DerJacques 6y ago
Could it be that you were using type-aware linting rules? If you have these rules enabled, ESLint basically has to compile all your TS files to check if the rules are followed. Note that most of the ESLint rules are _not_ type aware, but following the setup guides quickly has you turning them on “by accident”. For more details, see: https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/TYPED_LINTING.md https://github.com/typescript-eslint/typescript-eslint/blob/...
root_axis 6y ago
Been testing it out the beta, in my experience performance is better but still behind tslint, though tslint lacks a ton of rules compared to eslint so I am guessing that is partially why. I think the webstorm struggle is a webstorm specific issue, I've seen a few of my co-workers experience similar webstorm slow downs from eslint (and ts) but it works fine for me in vim without any slowdown of the editor itself.
dfee 6y ago
You’ll probably need to be more specific about the speed issues you’re seeing. I don’t see that issue, but I also factor my code into smaller packages in my monorepo (which is a good practice). I still have relatively long lint times against the monorepo (greater than a minute), but that’s part of the CI stage.

tobilg 6y ago

Hopefully it got a little less „dependency-heavy“ than before. Using eslint and babel tends to add 200mb of dev dependencies to a project...

Kaze404 6y ago
~ λ mkdir -p /tmp/js ~ λ cd /tmp/js /tmp/js λ npm init -y & npm i eslint babel [snip] /tmp/js λ du -h node_modules [snip] 36M node_modules
- tobilg 6y ago
  While this might be correct, in the a lot of cases you'll also use a lot of plugins for both to enable the desired transpilations and checks... I should have been more precise in my first comment though.

dwrodri 6y ago

I know the whole "there are two types of programming languages" Stroustrup quote applies to JS just as much as it does to C++, but can anyone comment on whether JS was hated as much as it was back when this second generation of browsers was being built? As someone who went straight into research and low-level work, I don't touch JS very often, but it seems to me as though the Web is in this arranged marriage it doesn't like, but refuses to leave because of the inconvenience. I feel like in some regards, we have seen generational shifts in other languages. In domains where Perl, Java, and C++ used to dominate, we now have Go, Rust, and Python. Absolutely worth noting that with the exception of Python, there are probably still vastly more lines of C++/Java code running in production than Go/Rust. I kind of don't get how if JavaScript is so bad, then why do we now have things like Node?

Latty 6y ago
If I had to guess, I'd say Node is popular because the web has eaten the world, and if you already have a web app as the core of your development, it starts to make sense to make everything else just an extension of that, including your server so you can do things like server-side rendering. A lot of that development seems to be TypeScript too, which helps mitigate a lot of the problems of raw JavaScript, and the structural typing makes working with JSON (something now pretty universal too) far easier than with a lot of languages. There are a lot of things I hate about JavaScript itself, but TypeScript's type system is genuinely great.