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

61–70 of 93 posts

Re: ESLint 7.0

#61

Post by Lazare »

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.

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

Re: ESLint 7.0

#62

Post by bound008 »

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…

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)

Re: ESLint 7.0

#63

Post by hombre_fatal »

traes wrote: post #53
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…

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

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 "[(.

Re: ESLint 7.0

#64

Post by gfxgirl »

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.

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.

Re: ESLint 7.0

#65

Post by hombre_fatal »

gfxgirl wrote: post #64
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.

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…

You can tell prettier to ignore the next node: https://prettier.io/docs/en/ignore.html

Re: ESLint 7.0

#66

Post by iandev »

gfxgirl wrote: post #64
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.

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…

If your team consistently writes code that looks like your first example, you absolutely shouldn't use prettier. However, in my experience, your first example isn't what people regularly produce and the output is a wild improvement on a lot of things that I've seen people write.

Re: ESLint 7.0

#67

Post by vips7L »

gfxgirl wrote: post #64
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.

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…

While I agree about the arrays. I much prefer the function call.

Re: ESLint 7.0

#68

Post by haolez »

hkai wrote: post #56
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…

TypeScript.

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.

Re: ESLint 7.0

#69

Post by traes »

hombre_fatal wrote: post #63
traes wrote: post #53

Earlier quoted context omitted.

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

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

Introducing any mental overhead to eliminate a single character per line at most seems a tad ridiculous.

Re: ESLint 7.0

#70

Post by Kaze404 »

Bishonen88 wrote: post #34
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.

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