ESLint 7.0 | Better HN

ESLint 7.0 | Better HN

90 comments

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

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

It should be renamed 'uglier' or 'obfusticate'

    const normals = [
      -1, -1, -1,
       1, -1, -1,
      -1,  1, -1,
       1,  1, -1,
      -1,  1,  1,
       1,  1,  1,
    ];

    const positions = [
      -1, -1,  0,
       1, -1,  0,
      -1, -1,  0,
      -1, -1,  0,
       1, -1,  0,
       1,  1,  0,
    ]

    ctx.drawImage(
       image,
       srcX, srcY, srcWidth, srcHeight,
       dstX, dstY, dstWidth, dstHeight,
    )

becomes

    const normals = [-1, -1, -1, 1, -1, -1, -1, 1, -1, 1, 1, -1, -1, 1, 1, 1, 1, 1];

    const positions = [
      -1,
      -1,
      0,
      1,
      -1,
      0,
      -1,
      -1,
      0,
      -1,
      -1,
      0,
      1,
      -1,
      0,
      1,
      1,
      0,
    ];

    ctx.drawImage(
      image,
      srcX,
      srcY,
      srcWidth,
      srcHeight,
      dstX,
      dstY,
      dstWidth,
      dstHeight
    );

Those are less pretty and useful info is lost.

tomduncalf5y ago

Yeah, prettier rocks. I was skeptical for a long time and if I’m honest and think about it I still don’t like some of the formatting choices it makes, but I don’t notice because of how fluid and pleasant it makes writing code. As an aside, often the “workarounds” result in clearer code, e.g. long formulas getting split up weirdly leads to me splitting stages of the calculation into named variables, which actually reads much better when I return to it months later.

No worrying about formatting code as I type, no worrying about checking style on PRs... definitely worth the trade offs for me, I enable it on every project I work on now.

yeah, I pretty much rely on eslint and prettier across the board... I do have a couple tweaks though[1].

1. https://gist.github.com/tracker1/e6c2befae41856da27973cf22cf...

TypeScript. ( + ESLint, + Prettier ). It has made writing JavaScript tolerable. Classes as you expect them. With proper editor support, you get real errors, and the whole thing starts to feel more like writing code in python. It is no python, but at least it feels significantly less foreign. Its very progressive in the sense that regular JavaScript is valid TypeScript, and everything else is just a cherry on top. And it is easy to include the typing outside of the source file, so many libraries not written at all in TypeScript have typing support built in (likely by simple PRs from the community)

traes5y ago

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

DCoder5y ago

This is like asking "vim or emacs". You'll never change anyone's mind on the matter, but you'll get the same old arguments from ~ten years ago [0] about how this is both "very simple†" and "pointless mental overhead" at the same time.

† (if you follow these rules I memorized to show off how smart I am).

---

[0]: https://github.com/twbs/bootstrap/issues/3057

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.

hombre_fatal5y ago

You need to know when semicolons are necessary whether you use them or not.

And the whole point here is that tooling eslint/prettier prevents bugs.

Prettier will turn this:

    const x = foo()
    [1, 2, 3].forEach(...)

into this:

    const x = foo()[1, 2, 3].forEach(...)

Which makes the problem pretty obvious.

Btw, if you decide to avoid semicolons, one of the only rules you need to know is to prefix any line with a semicolon if it starts with "[(.

soulofmischief5y ago

After every single line is not minimal. It's redundant.

In 30 minutes you can learn to recognize and practice handling all of the cases where a semicolon would be necessary. There is no ambiguity because the rules for statement termination are rigid. If you find it hard to navigate with only explicit semicolons, then you should brush up on your JavaScript knowledge.

And seeing as how we're on an ESLint thread... there are tools for that. ;)

I used always have semi-colons too, but now that my code is always transpiled, I just let the transpiler handle it (and TypeScript does a good job catching ambiguities/unintended code pretty well too).

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

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

The point of these tools is that the configuration is specified in the project, and works regardless of the developer's workflow.

hkai5y ago

TypeScript.

haolez5y ago

My use of JavaScript is mainly for small code bases. The gains of TypeScript are less relevant in this scenario over the bureaucracy that it brings to the game.

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

How is that different than:

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

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

Feature request #2: https://github.com/eslint/eslint/issues/11806

RFC: https://github.com/eslint/rfcs/tree/master/designs/2019-desc...

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

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

httgp5y ago

You could be commenting functions too (day JSDoc it TSDoc) but also want to do an eslint-ignore. It looks better then, IMO.

shpx5y ago

Yo dawg, heard you like comments

kbd5y 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)?

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

Haven't ran into too many issues within the last 8 months or so. Only in Spring 2019 was it bad IME.

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

baggachipz5y ago

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

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

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/

> 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 :)

Lazare5y ago

> I just could not deal with such an opinionated tool.

ESLint is not opinionated.

> ESLint would not let us adjust settings to accept some of our normal convection's and company code style guidelines.

Example?

> I switched to jshint and have lived a much happier life.

JSHint is more opinionated and less configurable than ESLint.

I have to ask, but uh...did you maybe get the names of the tools mixed up?

yepthatsreality5y ago

I feel this way but about `prettier.js` (as opposed to eslint.js) instead.

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

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

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

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

DerJacques5y 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/...

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

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

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?

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

moltar5y ago

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

huy-nguyen5y ago

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

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.

I think that's part of the typescript plugin, not part of eslint core - https://github.com/typescript-eslint/typescript-eslint/blob/... (I assume that means it only works on TypeScript.)

But, I agree with your point, that rule can catch a lot of bugs.

krainboltgreene5y ago

There are many ways to get this rule, but the primary one being: https://www.npmjs.com/package/eslint-plugin-promise

zymhan5y ago

We use Pulumi and Typescript, and it seems to rely heavily on Promise. I wonder how that ESLint rule would affect Pulumi code?

https://www.pulumi.com/docs/intro/concepts/programming-model...

dfee5y ago

I’m not sure on Pulumi specifically, but a .catch on a non-awaited promise should be fine.

z3t45y ago

If you add a catch block it will be even worse, all errors inside a promise callback will then become soft errors. Only add the catch if you actually plan to handle the error.

hombre_fatal5y ago

promise.catch(console.error) is still handling the error.

tengbretson5y ago

I can't speak to the front-end, but there are plenty of situations in dealing with node where the correct thing to do is to throw a fatal error. If you have properly setup handlers for the end of the process lifecycle I don't see what the problem is.

But until recently an unhandled promise failure was NOT a thrown error, and when it is it's not the error you want.

ausjke5y ago

hundreds of rules to read, is this on its recommended list if it's so critical? is its name 'no-floating-promises'?

williamdclt5y ago

> is its name 'no-floating-promises'

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

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!

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.

>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/issue...

dang5y ago

Please don't use uppercase for emphasis. If you want to emphasize a word or phrase, put asterisks around it and it will get italicized.

https://news.ycombinator.com/newsguidelines.html.

edflsafoiewq5y ago

HNLint

Thanks!

HN should automatically detect this and let me know :D

Unfortunately I think the comment is too old to edit.

j / k navigate · click thread line to collapse