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.
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.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.
1. https://gist.github.com/tracker1/e6c2befae41856da27973cf22cf...
Why would... you want that? You're trading minimal syntactic noise for possible ambiguity errors. You don't really gain anything.
† (if you follow these rules I memorized to show off how smart I am).
---
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 "[(.
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. ;)
// 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... // Here's a description about why this configuration is necessary.
// eslint-disable-next-line no-console
console.log('hello');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.
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.
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.
I switched to jshint and have lived a much happier life.
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 :)
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?
~ λ cd /tmp/js
/tmp/js λ npm init -y & npm i eslint babel
[snip]
/tmp/js λ du -h node_modules
[snip]
36M node_modules
I should have been more precise in my first comment though.
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.
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?
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.
Please use that rule. So many bugs in the JS world is because of dangling promises.
But, I agree with your point, that rule can catch a lot of bugs.
https://www.pulumi.com/docs/intro/concepts/programming-model...
Yes, and I subscribe to the parent's sentiment: this rule is essential
That's the name!
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...
HN should automatically detect this and let me know :D
Unfortunately I think the comment is too old to edit.