Skip to content

Commit

Permalink
recommended shared config (#402)
Browse files Browse the repository at this point in the history
  • Loading branch information
benmosher committed Jul 7, 2016
1 parent 45eab4f commit a55cd67
Show file tree
Hide file tree
Showing 4 changed files with 46 additions and 1 deletion.
6 changes: 6 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,11 @@ This project adheres to [Semantic Versioning](http://semver.org/).
This change log adheres to standards from [Keep a CHANGELOG](http://keepachangelog.com).

## [Unreleased]
### Added
- `recommended` shared config. Roughly `errors` and `warnings` mixed together,
with some `parserOptions` in the mix. ([#402])
- `react` shared config: added `jsx: true` to `parserOptions.ecmaFeatures`.

### Breaking
- [`import/extensions` setting] defaults to `['.js']`. ([#306])
- [`import/ignore` setting] defaults to nothing, and ambiguous modules are ignored natively. This means importing from CommonJS modules will no longer be reported by [`default`], [`named`], or [`namespace`], regardless of `import/ignore`. ([#270])
Expand Down Expand Up @@ -280,6 +285,7 @@ for info on changes for earlier releases.
[#157]: https://github.com/benmosher/eslint-plugin-import/pull/157
[#314]: https://github.com/benmosher/eslint-plugin-import/pull/314

[#402]: https://github.com/benmosher/eslint-plugin-import/issues/402
[#386]: https://github.com/benmosher/eslint-plugin-import/issues/386
[#373]: https://github.com/benmosher/eslint-plugin-import/issues/373
[#370]: https://github.com/benmosher/eslint-plugin-import/issues/370
Expand Down
12 changes: 11 additions & 1 deletion config/react.js
Original file line number Diff line number Diff line change
@@ -1,8 +1,18 @@
/**
* - adds `.jsx` as an extension
* Adds `.jsx` as an extension, and enables JSX parsing.
*
* Even if _you_ aren't using JSX (or .jsx) directly, if your dependencies
* define jsnext:main and have JSX internally, you may run into problems
* if you don't enable these settings at the top level.
*/
module.exports = {

settings: {
'import/extensions': ['.js', '.jsx'],
},

parserOptions: {
ecmaFeatures: { jsx: true },
},

}
27 changes: 27 additions & 0 deletions config/recommended.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
/**
* The basics.
* @type {Object}
*/
module.exports = {
rules: {
// analysis/correctness
'import/no-unresolved': 'error',
'import/named': 'error',
'import/namespace': 'error',
'import/default': 'error',
'import/export': 'error',

// red flags (thus, warnings)
'import/no-named-as-default': 'warn',
'import/no-named-as-default-member': 'warn',
'import/no-duplicates': 'warn',

This comment has been minimized.

Copy link
@jfmengels

jfmengels Jul 7, 2016

Collaborator

I find that warnings achieve very little and rarely put warnings in recommended configurations.
Sure, having duplicates for instance will not create errors, but in the context of ESLint settings, that would warrant an error level IMO. It is pretty easy to override, so I wouldn't let that hinder having them be errors.

I would also specify every rule, even if just to set it to off. That makes it easier to copy-paste all the rules for those who would prefer to do it that way.

},

// need all these for parsing dependencies (even if _your_ code doesn't need
// all of them)
parserOptions: {
sourceType: 'module',
ecmaVersion: 6,
ecmaFeatures: { experimentalObjectRestSpread: true },
},
}
2 changes: 2 additions & 0 deletions src/index.js
Original file line number Diff line number Diff line change
Expand Up @@ -27,6 +27,8 @@ export const rules = {
}

export const configs = {
'recommended': require('../config/recommended'),

'errors': require('../config/errors'),
'warnings': require('../config/warnings'),

Expand Down

2 comments on commit a55cd67

@jfmengels
Copy link
Collaborator

@jfmengels jfmengels commented on a55cd67 Jul 7, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just changed the way I created the recommended config in one of my plugins. I now put them all in the rule meta docs field, then loop over each. jfmengels/eslint-plugin-lodash-fp@97a04ab I think I'll use something like this in my other plugins too. I have tests that make sure that all rules appear in the recommended config.

The same system could be adapted to create multiple configs (recommended, errors, warnings...) should you want it.

@benmosher
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, super cool idea! I am torn a little, because I like being able to put relevant comments in the config source, and that gets lost if it comes from the meta... but then again, then the docs can automagically keep up with the shared states of the rule ("This rule is included with:"...)

I will mull it over. It's probably a good time, since a major version is nigh.

Please sign in to comment.