standard-strict

[rstacruz]

What are your thoughts on making eslint-config-standard-strict?

This would be extra rules on top of eslint-config-standard that would add more checks, like:

• no-div-regex (to catch return /=foo/)
• no-invalid-this (to catch () => this)
• no-unused-expressions
• camelcase
• and so on...

At first, it can be not integrated into standard at all, but eventually can be added as standard --strict and standard.lintFiles({ strict: true }). This will also set the precedent that we can have --no-react or similar flags.

[dcousens]

no-invalid-this (to catch () => this)

What is wrong with that?

[rstacruz]

Because that will raise an error in strict mode.

[pbrinkmeier]

I like the idea, but I would keep standard optionless and create this as standard-strict, as a seperate package.

[yoshuawuyts]

yeah, we should avoid having options. @rstacruz have you raised those rules to be considered in individual issues? I'm not familiar with all of them, but perhaps they'd be a good addition.

[rstacruz]

aye, a separate package makes sense. they were /sorta/ discussed in #216, with an exhaustive list of differences from xo here: #216 (comment)

nonetheless, i think it makes sense to do it in a separate package at first (think of it as "standard-staging"), and we can eventually migrate rules into upstream standard. It really is no big deal to build it as a separate package, it's basically:

/* eslintrc */
{
  "extends": [ "standard", "standard-react", "standard-strict" ]
}

[denis-sokolov]

Awkward...

[rstacruz]

nice one denis!

[rstacruz]

@dcousens @feross any thoughts on those additional rules?
https://github.com/denis-sokolov/strict-standard-config/blob/master/src/index.js

[feross]

Not completely against this idea. Need to think about it more.

[feross]

Here's another rule that would make sense for a stricter mode: #381

[feross]

Another rule: standard/eslint-config-standard#21

[dcousens]

Perhaps standard-strict could be allowed to break more often.

Make it the bleeding-edge of what can be expected in the next major version of standard?

[dcousens]

Maybe standard-next? :P

[feross]

One more rule: standard/eslint-config-standard#19

[rstacruz]

https://github.com/denis-sokolov/strict-standard

@denis-sokolov did some fine work on this.

[cesarandreu]

@dcousens @feross Are you familiar with codemods? There's a Facebook library jscodeshift that lets you apply AST transformations to JS code, instead of doing text transformations.

It may be worth considering writing a few transforms for breaking changes. Even if they don't catch all the cases, it makes it much easier for people to upgrade their projects.

[feross]

@cesarandreu Neat. This could come in handy for standard-format.

[dcousens]

I'd say this has lost steam. Close?

[feross]

We've basically been making standard slightly stricter with each release, but not too fast that users get upset or find it disruptive.

Now that we have --fix and it works really well, I'm more certain that that this is the right strategy to continue taking in standard.