ESLint 7.0(eslint.org) |
ESLint 7.0(eslint.org) |
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,
)
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
);
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(...)
const x = foo()[1, 2, 3].forEach(...)
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');
// 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
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.
Asking because to me personally it seems that it's easy to create a new TypeScript app from a template with zero configuration, and then it just works. Perhaps I'd need to spend 5 minutes to write the type for the API responses or some other basic stuff like that.
The theme was primarily made for me, but I published it because others might find the idea useful.
Frankly, I die inside every time I work with a semicolon codebase and have to move a semicolon just to chain onto:
promise
.then()
.catch();
+ .then();
foo
.bar()
.baz();
+ .qux();
I challenge you to try it the next time you write some Javascript. Don't use semis and remember the one rule I taught you.
Sometimes I can't use another tool because another dev has snuck the change into the repo. I can't be privy to every change at a large company. I also can and will continue to be bothered by the existence of prettier because of this. Sometimes I like being bothered. It let's me know what kind of crap to avoid in the wild. If this explain bothers you, you should consider other contexts where problems may apply.
You're mixing so many different things right now.
The one thing I'll give to you is the handling of arrays. There is an open issue to treat array literals the same as object literals in that newlines between elements will be respected and not automatically compressed onto a single line if the whole line is less than max-width. After about a half year of usage that's the only default I really don't like.
Clearly for projects where devs have the habit and follow a clear style, it's not necessary. However on mosy projects, you'll have the one guy who doesn't follow, or worse, the only one guy who follows the style. And so the prettifiers become absolutely necessary.
I'll bite - why, exactly, is this "absolutely necessary"? The justifications for needing style guides and linters that I get is usually something like "so we don't argue about this stuff". Well... I wasn't arguing in the first place - you were. And every project will have someone who wants to add their own preference in 'because'... so regardless of what you're in, nothing is 'standard', ever.
My experiences may be somewhat outside the norm, but in the last... 18 months or so, I've worked with 3 different teams (anywhere from 3 to 20+ other people) across php, js - angular/vue/node, java and ruby. There's been more in-fighting and bike-shedding about "standards" from people who tend to be the least productive.
I can fully admit some code is, sometimes, easier to read when formatted certain ways. No one seems to ever be able to admit or acknowledge that sometimes, it's very hard for me to read in their preferred style. I don't complain. I just ... get on with it.
Again, my experience may be different from others, but of the multiple folks I've dealt with in the past couple of years, the ones who were open vocal advocates about needing "standard" and forcing style/linting/etc on to projects - these people rarely ever found bugs in their own code or code from others, or spotted logical problems with the code, or, indeed, contributed tests. It's as if they equate 'code beauty' with the actual functioning of the code itself. "Hey, it looks good, I'm checking it in" - this is now reinforced with "hey, all my linting/style is passing - awesome - checking it in!"
I initially chalked this up to one person, but in my experiences, it's been a recurring trait/behaviour.
I jump between projects/contracts. I've never worked at one company on one project and one team for multiple years - the dynamics are certainly different from short term projects.
Current situation - two client projects.
Client A - fanatical about 'null==' because there was some bad assignment by mistake issue a few years back. This is a hard rule, and code will be blocked if you commit
if (customer.id == null)
if (null == customer.id)
However - working with client B
if (null == customer.name)
So, in the same week (sometimes, the same day), I have multiple competing styles in my head, and regardless of what I do, I have a productivity loss because something has to check/correct and I have to wait, or I have to recommit and re-push stuff because something was 'wrong' to someone. When you switch between "styles" enough, it begins to seem a bit cargo-cultish, to my eyes.
def some_function(arg1, arg2, arg3):
temp=arg1*arg2;temp=numpy.some_function(temp, arg3);return temp
I was almost useless work. Worse yet, we couldn't fire him because we were mandated by higher ups to keep him in the team for the duration of the internship he had to do to comply with some scholarship requirement with an institution we're related.
Again, the style guide we've written works for our team and the #1 rule is: code must be clear. There are a few other rules (variables and functions are snake_case, classes are CamelCase and so on), but those are derived from #1 and habits/experience the team has developed over years of work.
I also understand they situation you say: putting style/beauty/the linters as an objective and forgetting about what the code has to do in the first place. Can't really help you there, I am aware (and happy) that my team and I are in sync.