Be more lax about peer dependencies in eslint-config-react-app

When using CRA with an additional linter I hit problems with matching peer dependency versions with eslint-config-react-app. It has absolute requirements for its peer dependencies.

{
  "peerDependencies": {
    "babel-eslint": "7.0.0",
    "eslint": "3.8.1",
    "eslint-plugin-flowtype": "2.21.0",
    "eslint-plugin-import": "2.0.1",
    "eslint-plugin-jsx-a11y": "2.2.3",
    "eslint-plugin-react": "6.4.1"
  }
}

(https://github.com/facebookincubator/create-react-app/blob/a5f760bab9b1876df13ac4345a4b42655fec46fa/packages/eslint-config-react-app/package.json)

Specifically babel-eslint, eslint, and eslint-plugin-react is hard not to clash with. I had another eslint-config that listed all three of them with incompatible versions. As an example it listed eslint as ^3.11.0.

Had eslint-config-react-app used the caret-style dependencies for it’s peer dependencies, it would have worked out fine.

In general, I understand why you might want to absolutify your linter dependencies - there’s nothing more annoying than lint errors showing up on CI that you didn’t catch locally. But in this case, where it’s very common to add another linter setup I think it might be worth it, to be more lax about the requirements.

For my case, pinning the versions listed in peerDeps of eslint-config-react-app got rid of the peer dependency warnings, after I had downgraded the requirements in the other eslint-config I used.

Would you be open to widen the peer dependency version ranges in eslint-config-react-app?

[gustavnikolaj]

@fson I completely understand your stance on this matter, and I agree wholeheartedly. But I think that it is better controlled from the projects themselves and not by third party library code. In my opinion, both CRA and eslint-config-react-app fall into the latter category.

As a user of CRA I’d expect that I could just run npm install --save-dev standard and add a lint script to my package.json and be up and running. That will not work without triggering peerDependency warnings if standard relies on a package that is too newer than one defined in eslint-config-react-app. As of writing, this will actually work, as the most recent version of eslint-config-standard has a peer dependency on eslint >=3.8.1. If that was changed to >=3.8.2 we would start seeing the issue I described.

Most of the sharable eslint configurations that I have seen are using peerDependencies with either caret or greater-than-or-equal to, to avoid dependency hell. A few examples:

• standard: https://github.com/feross/eslint-config-standard/blob/c879dfb71e03739a45e980687f9a28c94b4a95d2/package.json#L48-L52
• xo: https://github.com/sindresorhus/eslint-config-xo/blob/f1ab27f578738706658ae35cc549e5114015c68a/package.json#L58-L60
• airbnb: https://github.com/airbnb/javascript/blob/1ab6aaede9b146235d22b643d5f5076f7daa9b2e/packages/eslint-config-airbnb/package.json#L63-L68

Doing the same here will allow people to get off the ground easily, with no friction, but still allowing them to freeze packages using shrinkwrap / yarn or manually adding absolute versions for the important packages.

[gaearon]

Fixed in the latest version of the preset.