Stylelint gives us protection from various CSS issues. Let's do the same for our JS.
eslint is the most mature and provides a list of rules we can make use of if we deem the need.
npm install eslint --save-dev
In package.json, add a new command
"lint:js": "eslint openlibrary/plugins/openlibrary/js/"
Add an .eslintrc.json
{
"root": true,
"env": {},
"globals": {
},
"rules": {
"no-extra-semi": "warn"
}
}
We'll set the errors to warn for the time being and as soon as the config is merged we should coordinate with someone to run the fixes and merge to avoid any merge conflicts!
Hi. Can you assign me to resolve this issue?
Question: why not to use one of presets for eslint
? Like https://standardjs.com or https://github.com/airbnb/javascript
Long term I'd like to but the javascript is in such a bad shape applying such a preset would be a lot of confusing (code review, rebase conflicts) and manual work (most of the preset cannot be autofixed). I think manually adding rules helps us attack it bit by bit in a cohesive and educational way (we learn about the problems in our code bit by bit).
I figured we could use the linting to iron out the most common and pressing issues (the lints that can cause errors in code) and then at our leisure apply a preset (of our choosing) later down the road.
Does this make sense?
Sure, it does. Code shape can be very bad.
When this PR will be merged I can fix some issues with linting, just name em.
Will start with no-extra-semi
for example ;)
@tamtamchik i can create an issue later but anything that is under "possible Errors" snd and autofixable is fair game.
We should coordinate with @mekarpeles to run and commit the autofixes and make eslint error rather than warn.
I want us to get rid of the low hanging fruit !