feat: Allow eslint customization per project?

[bebraw]

Context: webpack-contrib/uglifyjs-webpack-plugin#35 (comment) .

To make it easier to port projects to defaults, it would make sense to allow local ESLint overrides (should be removed later but this helps in getting over the hedge).

[sapegin]

Just don’t commit changes to .eslintrc ;-)

We need a list of properties that should be always overwritten, removed, etc.

[bebraw]

Ok, I would leave rules out and override rest.

[michael-ciniawsky]

That would likely end up in having different styles across all repos then, but yes I also struggled a few times with eslint-config-webpack, when trying to update repos with webpack-defaults. But since I'm normally using Standard and nevermind setting up ESLint etc. :) I didn't found the time to shape up on how to setup an ESLint Config in general and investigate which rules could be relaxed or removed (eslint-config-webpack is too strict imho). What about using either Standard(-ish) (it's not gonna happen 😉 I suppose) or Prettier ? Didn't tested the latter yet tbh, so no idea if this actually would make it easier to handle some of our 'unique' code bases 😛 . Subjectively and what I personally like about e.g standard is that it isn't getting in my way too much compared to eslint-config-webpack

// Relaxed in standard, complains with eslint-config-webpack
...map(x => x * 2)
...map((x) => x * 2)

const a = x === 42 ? y : z 
const a = x === 42
  ? y
  : z

And... 😛

const obj = {
   a: 'foo',
   b: 'bar', <= comma dangle 🤢 
}

[sapegin]

+1 for Prettier as ESLint plugin. And it can be set up to insert dangling commas which is also cool ;-)

[bebraw]

Yeah, 👍 for Prettier. Also eslint rule relaxation in certain cases. That's better than overrides.

[sapegin]

Are these our custom rules or there are from Airbnb?

[joshwiens]

@sapegin - These rules started out based on Airbnb, the deprecations were removed and then the rules we didn't agree with were updated over time.

[joshwiens]

A thought. I'm all for using Prettier but at some point we need to call this good ( enough ) and get the initial work done.

For the initial push to get everything up to date, imo we should leave things as they are less bugs, commit what we need to the .eslintrc or update the config and get the upgrades done.

Target using Prettier for webpack-defaults@2.0.0 tweak all the repos with 2.x when we add schema-utils to everything on the second wave of updates which can be done as a chore and won't require a semver: Major like this first pass.

Personally I think there is more value to both consumers & maintainers to get defaults 1.x out to include test suites for loaders that don't have them. The lack of engines & peerDeps definitions is going to start biting us in the ass more and more and the rest of the JavaScript world keeps driving forward.

[joshwiens]

I really need to pay attention to which github account I am on when commenting ...

[joshwiens]

There really is no need to allow customizations nor is there a good place to draw the line.

This standards thing exists because it makes it easier to context switch between projects when maintaining. It's interesting that style has been the most discussed topic since contrib started, particularly given that it is familiarity not style that increases readability. We could write our JavaScript in crayon and in six months it would be readable

Everyone wants to use Prettier in 2.x, fine. It makes very little difference to me given everything we write is transpiled anyway. Which every way the wind blows this time, they will all be the same and none of them change until we are finished with the more pressing work.

Just keep in mind that six months from now, someone, somewhere will want to use JS Standard or whatever comes next. You can't please everyone nor is it in our mandate to do so.

[joshwiens]

Closing in favor of the working issue for Prettier integration ( #84 )