[HN Gopher] ESLint 7.0
___________________________________________________________________
ESLint 7.0
Author : himynameisdave
Score : 142 points
Date : 2020-05-11 15:42 UTC (7 hours ago)
(HTM) web link (eslint.org)
(TXT) w3m dump (eslint.org)
| baggachipz wrote:
| Ah ESLint, the most necessary bane of my existence. Good work to
| the team for the update.
| PretzelFisch wrote:
| 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.
| yepthatsreality wrote:
| I feel this way but about `prettier.js` (as opposed to
| eslint.js) instead.
| MatekCopatek wrote:
| That's expected - Prettier intentionally and openly
| positions themselves at the most extreme extreme end of
| convention-over-configuration. Their tagline is
| "Opinionated code formatter". If this bothers you, you
| should look for a different tool.
| jakub_g wrote:
| 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 :)
| huy-nguyen wrote:
| Does this release support Yarn v2's Plug'n'Play?
| tobilg wrote:
| Hopefully it got a little less ,,dependency-heavy" than before.
| Using eslint and babel tends to add 200mb of dev dependencies to
| a project...
| sadturnip wrote:
| 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 wrote:
| 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_axis wrote:
| 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 wrote:
| 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.
| kbd wrote:
| 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 wrote:
| 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.
| [deleted]
| nikaspran wrote:
| 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.
| tuukkah wrote:
| 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...
| mikewhy wrote:
| 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 wrote:
| You could be commenting functions too (day JSDoc it TSDoc)
| but also want to do an eslint-ignore. It looks better then,
| IMO.
| tuukkah wrote:
| 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.
| jrrrr wrote:
| 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.
| shpx wrote:
| Yo dawg, heard you like comments
| aaomidi wrote:
| 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 wrote:
| hundreds of rules to read, is this on its recommended list if
| it's so critical? is its name 'no-floating-promises'?
| aaomidi wrote:
| 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!
| williamdclt wrote:
| > is its name 'no-floating-promises'
|
| Yes, and I subscribe to the parent's sentiment: this rule is
| essential
| brycelarkin wrote:
| https://github.com/typescript-eslint/typescript-
| eslint/blob/...
| tengbretson wrote:
| 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.
| ergothus wrote:
| But until recently an unhandled promise failure was NOT a
| thrown error, and when it is it's not the error you want.
| tengbretson wrote:
| Absolutely! I guess what I'm trying to say is that in my
| experience, crashing on an unhandled rejection is a better
| remedy to the dangling promise problem than banning them
| outright.
| z3t4 wrote:
| There is a saying - what you don't know can't hurt you. The
| idea of Promises comes from strongly typed static
| functional languages. Adding it to JavaScript was a
| terrible idea. Like with static modules - forcing the user
| to download the whole website/app before anything is
| rendered on the screen.
| aaomidi wrote:
| Lol what are you on about.
|
| You're mixing so many different things right now.
| dang wrote:
| _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.
| edflsafoiewq wrote:
| HNLint
| z3t4 wrote:
| 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.
| nfriedly wrote:
| 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.
| krainboltgreene wrote:
| There are many ways to get this rule, but the primary one
| being: https://www.npmjs.com/package/eslint-plugin-promise
| vimslayer wrote:
| I don't think that plugin catches floating promises, i.e.
| promises that are not waited (either via await or
| then/catch method). The rules listed in that package's
| readme don't seem to mention it at least (unless I'm
| totally misreading something). You kinda need TypeScript
| for that because you need the type info to know if a value
| whether some value is a Promsie to give the warning.
| zymhan wrote:
| 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...
| dfee wrote:
| I'm not sure on Pulumi specifically, but a .catch on a non-
| awaited promise should be fine.
| haolez wrote:
| 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.
| vorpalhex wrote:
| 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.
| tomduncalf wrote:
| 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.
| Drdrdrq wrote:
| And if you are working in a team it makes those arguments
| about styling moot. One of the best aspects of JavaScript.
| tomduncalf wrote:
| Yeah that's what I mean about PRs - such a time saver to
| not discuss trivial code style issues and be able to just
| focus on the code itself!
| _virtu wrote:
| I'll never forget getting our team of 90+ devs to move to
| prettier because of this argument and then having team
| members proceed to strong arm me to change the configs to
| things that they preferred six months after we made the
| move and we had adopted it across over 10 different
| repos. Talk about counter to the whole point of using
| such a wonderful tool.
| Bishonen88 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2020-05-11 23:00 UTC)