Using eslintrc from the project

standard / standard-engine

:fire_engine: The guts of `standard` modularized for reuse

MIT License

145 stars 39 forks source link

Using eslintrc from the project #47

Closed rstacruz closed 8 years ago

rstacruz commented 8 years ago

https://github.com/feross/standard/issues/351#issuecomment-170360310

It'd be nice for standard-engine to pick up your local .eslintrc. You can set your eslintrc to this, and customize it as you see fit.

{
  "extends": ["standard", "standard-react"]
}

Rationale:

be able to use (or not use) standard-react (ouch)
be able to use semistandard (or similar)
you can disable rules if you really really want to
use standard-engine (which is much better than eslint's own CLI, imho!) with other eslint rules
use tape-standard, mocha-standard and similar with other eslint rules

As a bonus, maybe it can be defined in package.json as an alternative (much like babel lets you define options in .babelrc and package.json/babel)

Flet commented 8 years ago

Could this be built as a separate CLI tool on top of standard-engine? A lack of configuration/options/deviation was one of the original goals of standard, and allowing everything to be overridden by a local .eslintrc may undermine that goal.

It could also get confusing if someone has an old .eslintrc file in their project and things start acting strange (I guess this would be the "breaking" part).

I do like this idea though! We could add it as a configurable option to standard-engine but I don't know how keen @feross and others would be on adding it to standard.

feross commented 8 years ago

Is this a simple matter of allowing the user to set the useEslintrc eslint option? If that's all it is, I don't see the harm in letting users of standard-engine set it.

That said, it was an explicit decision to not do this for standard itself, as this would make standard behave differently on different machines, if a user keeps their code in ~/code and a config file in ~/.eslintrc, which actually bit me once.

I think the solution that standard will offer for this is to just allow rule overrides directly in package.json for those who just need to change a rule or two for their project. But that's separate from this issue.