71–80 of 93 posts
Hopefully it got a little less „dependency-heavy“ than before. Using eslint and babel tends to add 200mb of dev dependencies to a project...
~ λ cd /tmp/js
/tmp/js λ npm init -y & npm i eslint babel
[snip]
/tmp/js λ du -h node_modules
[snip]
36M node_modules
Earlier quoted context omitted.
I feel this way but about `prettier.js` (as opposed to eslint.js) instead.
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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…
Hopefully it got a little less „dependency-heavy“ than before. Using eslint and babel tends to add 200mb of dev dependencies to a project...
~ λ mkdir -p /tmp/js ~ λ 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.
Earlier quoted context omitted.
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.
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.
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.
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.
Earlier quoted context omitted.
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.
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.
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.
† (if you follow these rules I memorized to show off how smart I am).
---