Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESLint 7.0

eslint.org

Post reply on HN
Print view View original

31–40 of 93 posts

Re: ESLint 7.0

#31

Post by z3t4 »

ergothus wrote: post #27
tengbretson wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: ESLint 7.0

#32

Post by jakub_g »

PretzelFisch wrote: post #28
baggachipz wrote: post #2

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

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

Re: ESLint 7.0

#33

Post by krainboltgreene »

nfriedly wrote: post #20
aaomidi wrote: post #7

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.

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

Re: ESLint 7.0

#34

Post by Bishonen88 »

haolez wrote: post #3

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 gene…

You can do most of that without ESLint for any programming language with an IDE. Speaking about jetbrains intellij/pycharm from my own experience.

Re: ESLint 7.0

#35

Post by tomduncalf »

vorpalhex wrote: post #18
haolez wrote: post #3

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 gene…

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.

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.

Re: ESLint 7.0

#36

Post by tengbretson »

ergothus wrote: post #27
tengbretson wrote: post #24

Earlier quoted context omitted.

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.

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.

Re: ESLint 7.0

#37

Post by DerJacques »

sadturnip wrote: post #13

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.

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

Re: ESLint 7.0

#38

Post by brycelarkin »

williamdclt wrote: post #9
ausjke wrote: post #8

Earlier quoted context omitted.

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

> is its name 'no-floating-promises' Yes, and I subscribe to the parent's sentiment: this rule is essential

https://github.com/typescript-eslint/typescript-eslint/blob/...

Re: ESLint 7.0

#39

Post by Drdrdrq »

tomduncalf wrote: post #35
vorpalhex wrote: post #18

Earlier quoted context omitted.

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.

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 rea…

And if you are working in a team it makes those arguments about styling moot. One of the best aspects of JavaScript.

Re: ESLint 7.0

#40

Post by tomduncalf »

Drdrdrq wrote: post #39
tomduncalf wrote: post #35

Earlier quoted context omitted.

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 rea…

And if you are working in a team it makes those arguments about styling moot. One of the best aspects of JavaScript.

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!
Post reply on HN