Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Globally defining eslint overrides #367

Closed
rstacruz opened this issue Dec 25, 2015 · 7 comments · Fixed by standard/standard-engine#57
Closed

Globally defining eslint overrides #367

rstacruz opened this issue Dec 25, 2015 · 7 comments · Fixed by standard/standard-engine#57

Comments

@rstacruz
Copy link
Member

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
Copy link
Member

feross commented Dec 29, 2015

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.

@feross feross added v6 labels Dec 29, 2015
@Flet
Copy link
Member

Flet commented Dec 30, 2015

Would this be just for disabling rules?

@davidmarkclements
Copy link

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

@84564221
Copy link

84564221 commented Jan 6, 2016

@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
Copy link
Member Author

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
Copy link
Member

feross commented Feb 4, 2016

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

See the planned changes here: #399

@feross feross mentioned this issue Feb 4, 2016
25 tasks
feross added a commit to standard/standard-engine that referenced this issue Feb 4, 2016
So users can specify custom rules.

Works in `package.json`:

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

For user that need to tweak one rule for their particular project.

Fixes standard/standard#367
@feross
Copy link
Member

feross commented Feb 4, 2016

@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.

@feross feross closed this as completed Feb 4, 2016
@feross feross mentioned this issue Feb 7, 2016
10 tasks
@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

5 participants