
ESLint 7.0 - himynameisdave
https://eslint.org/blog/2020/05/eslint-v7.0.0-released
======
haolez
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.

~~~
traes
> to enforce the lack of semicolons

Why would... you want that? You're trading minimal syntactic noise for
possible ambiguity errors. You don't really gain anything.

~~~
bdefore
In combination with other linting rules to catch reckless conditionals and
multiline returns, it is absolutely safe to enforce no semicolons. And the
visual noise is, at least to my eyes, a significant impact.

~~~
wildpeaks
If visual noise is an issue, I made a VSCode theme specifically for muting
things like quotes and semicolons, that way I don't have to choose between
explicit semicolons and reduced visual clutter:
[https://marketplace.visualstudio.com/items?itemName=wildpeak...](https://marketplace.visualstudio.com/items?itemName=wildpeaks.wildpeaks-
theme)

The theme was primarily made for me, but I published it because others might
find the idea useful.

------
tuukkah
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-
rul...](https://eslint.org/docs/user-guide/configuring#disabling-rules-with-
inline-comments)

~~~
mikewhy
How is that different than:

    
    
      // Here's a description about why this configuration is necessary.
      // eslint-disable-next-line no-console
      console.log('hello');

~~~
tuukkah
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-desc...](https://github.com/eslint/rfcs/tree/master/designs/2019-description-
in-directive-comments)

Next up: an ESLint rule that makes the comment obligatory for disable
directives.

------
kbd
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
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.

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

~~~
PretzelFisch
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
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
Sorry this was me mixing up JSLint and ESLint

~~~
jakub_g
Ah, gotcha. JSHint was indeed created to fix JSLint's even greater non-
flexibility, long time ago.

------
tobilg
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
~ λ 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
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.

------
sadturnip
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
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/...](https://github.com/typescript-
eslint/typescript-eslint/blob/master/docs/getting-
started/linting/TYPED_LINTING.md)

------
dwrodri
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
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.

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

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

------
aaomidi
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
hundreds of rules to read, is this on its recommended list if it's so
critical? is its name 'no-floating-promises'?

~~~
williamdclt
> is its name 'no-floating-promises'

Yes, and I subscribe to the parent's sentiment: this rule is essential

~~~
brycelarkin
[https://github.com/typescript-eslint/typescript-
eslint/blob/...](https://github.com/typescript-eslint/typescript-
eslint/blob/master/packages/eslint-plugin/docs/rules/no-floating-promises.md)

