Closed jfroelich closed 5 years ago
Ok. Setup npm. Setup linter. Setup eslint. Setup babel. Setup package.json. Setup eslintrc. Setup jshint and jshintrc. Reconfigured atom to use 100 characters per line.
So, first I had no problems, now there are hundreds. Problem # 1, there are hundreds of errors per file, so I want to limit the errors. I figured that out, but all the initial errors are about import failures. So now this is a problem with Google Chrome extensions import syntax. Last I checked I must use a correct file path to an extension and I also must use the .js file extension in that path in order for an import to work within a Google Chrome extension.
First, maybe Google has since remedied module import behavior, so I need to look into whether alternate import syntax now works.
Second, I need to be able to configure the linters (both jshint and eslint) in Atom properly. This involves something like setting up a resolver or something, and thereby learning about all the complexities of those packages, none of which were ever designed for my particular use case. I don't even agree with some of these insane and strange rules.
To get eslint up and running initially I had to disable several rules. I eventually want to re-enable some of these rules.
Note that eslint does not correspond exactly to AirBnB. So I need to revisit its configuration, and I need to revisit the style guide rules themselves to ensure compliance. All I have done so far is conform to a custom configuration of eslint, which is not necessarily airbnb.
This issue is now mostly completed. There are some lingering things to think about. Also, I have very strong opinions about some of these, and disagree with them. So I added a few rules to eslint to override them.
In particular, wildcard imports are fine. Airbnb seems to be fighting the language. Modules are objects. You do not need to export only one thing. For some reason they seem to dislike modules.
for..of is really nice. Conventional for loops are great. Using map/reduce/filter etc is trendy garbage. It introduces a substantial loss in performance for very little (if any) increase in readability or maintainability or a reduction in error-pronedness. It is good in some spots but has no place at all in a style guide.
destructuring. it is nice in some places, and bad in others. I've noticed it leads to some difficult to parse code. forcing use in all cases is wrong.
dangling commas. i think this is remarkably one of the worst things i've ever seen. just ... no,.
isNaN is fine when the purpose is to determine if a value is a number. Number.isNaN does not help there and just leads to more verbose wacky wordaround boilerate and processing to get the same result. this is a silly rule.
shadowing is fine. shadowing is indeed risky. but nonsense.
not all functions are pure. setting a property on an input object is normal implementation code. sure we can try and write more pure functions but sometimes it is a stretch and it just leads to piles of garbage that are inelegant all just to try and maintain purity. this shouldn't be a linting error.