Globally defining eslint overrides

[rstacruz]

Is it possible? I know this was deliberately not possible to discourage bikeshedding, but hear me out here:

I'm using deku as an alternative to React. deku allows you to do <div class="foo"> when React insists on you doing className="foo". using class, however, makes standard throw an error:

Unknown property 'class' found, use 'className' instead (react/no-unknown-property)

I know I can disable this on a per-file basis, but this makes my boilerplate very cumbersome:

/* eslint-disable react/no-unknown-property */
/** @jsx element */
import element from 'magic-virtual-element'

Any other sane workarounds here?

[feross]

I'm sympathetic to this. We already support a globals property in package.json to avoid putting /* globals X */ at the top of every file. I think it's fine to add a rules property too. We can put this in v6.

[Flet]

Would this be just for disabling rules?

[davidmarkclements]

+1 to this - I'm having the exact same issue with react-blessed

[84564221]

@feross
Giving the user the ability to add custom rules would inevitably result in an infringement of §2.

The main alternative option would be to disable react specific linting rules.

[rstacruz]

I've switched my projects to use eslint and tape-eslint, but still using standard's config. Much saner—startup time is faster, I can disable standard-react, my projects don't contain standard-format bloat.

https://github.com/rstacruz/tape-eslint

[feross]

@rstacruz Nice! All of the tweaks you just described will be default in standard v6.

See the planned changes here: #399

[feross]

@askmatey I don't think this is an infringement of The Standard Way™, just an evolution.

I've been wanting to expose the underlying eslint configurability via package.json and command line options so that we can put an end to all the requests to support X, Y, or Z rule changes. It's true that the vast majority of these issues are bike-shedding, but there are a few legit issues like: #386 and this one for deku support.

In the past, I've rejected such things on the basis that we want to avoid configurability in standard, since that was kinda the whole point.

In the future, I want to move to a model where standard Just Works™ out of the box, but we expose the necessary hooks for those super-rare 1% edge cases where someone really needs to disable a rule or support something like Flowtype or deku in their project. That way we can keep the core lightweight.

Maybe we can even remove React support from standard in v6 or a future version! That would make it faster to install and run for the vast majority of standard users who don't use React.

Here's a PR to add support to standard-engine for setting rules: standard/standard-engine#57

Works in package.json:

{
  "standard": {
    "rules": {
      "semi": [2, "always"]
    }
  }
}

This will be released in standard v6.