Configure ESLint to lint source code at development time

[rchavarria]

As discussed in exercism/xjavascript#101 and exercism/xjavascript#26, ESLint seems to be a good tool to lint JavaScript and ECMAScript source code.

Add it and configure it to lint source code at development time.

[rchavarria]

exercism/docs#54 highly recommends the use of linters for all languages.

[rchavarria]

ESLint tool has been added in #81. Now, it's time to decide what should be linted and in what way. ESLint has lots of rules that can be checked, organized in several groups:

• Possible errors
• Best practices
• Discarded Strict mode
• Variables
• Discarded Node.js and CommonJS
• Let users decide Stylistic issues
• ECMAScript 2015

Note: updated after @matthewmorgan and @kytrinyx comments

[matthewmorgan]

@rchavarria At first consideration, without getting in to each of the available rules, it seems like we can omit two groupings:

1. Node.js and CommonJS: doesn't seem relevant. Am I wrong?
2. Strict mode: this declaration is not needed in ES6, right?

Include some:

1. Possible errors (most if not all)
2. Best practices (most if not all)
3. Variables (most if not all)
4. ES 2015 (some of this seems like it belongs in 'stylistic'?)

@kytrinyx On the 'stylistic issues,' should exercism be expressing an opinion on this, or should that be left to discussion between users? Do other tracks that lint express opinions about style?

[kytrinyx]

I think the stylistic questions should be left to the users in languages where there's traditionally more than one way to do things. In Python and Go, for example, it would make sense to encourage following the standard style guide. In Ruby (and probably JavaScript...) not so much!

[matthewmorgan]

I think this is resolved. Please let me know if not. Thanks everyone!

[rchavarria]

In my opinion, there's still some work to do here. Well, I have to admit that there hasn't been too much activity related to this issue recently, but there are some point like: Best practices or Variables that I would like to address (see comment above).

Are you ok with this? We could open a different issue, but I would prefer to reopen this one.

[matthewmorgan]

@rchavarria of course! that's why I asked. Sorry for overlooking the remaining tasks.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[tejasbubane]

@rchavarria Do you have any plans/ideas about implementing the best practices and variables you mentioned above?

[rchavarria]

When I started working on this some of these were true:

• I didn't know enough ESLint
• ESLint needed manual configuration for all that

Nowadays, configuring ESLint is much easier. I recently did it in my team. So, I prefer keeping this issue open, and I'll take care of this soon (within one week).

Depending on the number of errors found, it will generate some discussions, but I hope I can get most rules working without a huge effort.

[rchavarria]

I've been working on this on my own fork of the repo (configure-eslint branch)

It will have conflicts with other PRs, because some changes on ./package.json (and that file on each exercise). So I don't want to open a PR yet. But, I'll open it when all PR are merged and I resolve conflicts.

There are a lot of ESLint rules to discuss 😉

[matthewmorgan]

Hey @rchavarria, we've currently got 2 PRs open that affect the package.json files. Hoping to get those merged so you can get this resolved also. Thanks for being patient.

[rchavarria]

And both PR have files with conflicts 🤣

I need to do some additional work on the ESLint config, so I can wait a little bit more. Don't worry.

[tejasbubane]

@rchavarria Did you figure this one out?

[matthewmorgan]

@tejasbubane @rchavarria Let's hold off on this one pending outcome of #412

[valtism]

Not sure if this issue is the right place to bring this up, but I find it very annoying trying to do the javascript track while the exercise tries to enforce style rules on me. I use 4 spaces per tab (as I believe people should, to discourage deep nesting) but the exercise tries to enforce AirBnB style on my code. I can change this manually, but I think it would be better to explore a CLI option where the user can specify their code style starting the track, and applying this style across all exercises.

Also, I feel that if you really wanted to go with a single, opinionated styling rule, Prettier would be better.

Let me know thought and feelings around this.

[kytrinyx]

@valtism As far as I can tell, we don't enforce a particular style on the exercises, only on the development of the track itself, so that all the exercises are formatted consistently when delivered to people on the site.

[tejasbubane]

@matthewmorgan @rchavarria Can we proceed with the eslint integration now that the track migration is done? I am willing to lend a hand, let me know the approach.

[SleeplessByte]

Superseded by #681