given .eslintrc in filePath is not the only one considered - but also current and user folder's

around line 224 of index.js you are calling const config = configFinder.getConfigForFile(filePath); which ends up calling eslint/lib/config.js#getConfig() method

What I can see is that this method will compute the configuration not only using the given config file but also the current project config file, user’s config and probably other .eslintrc in the system.

In my case the manifested bug is that a .eslintrc file that doesn’t define a rule and should take the default value will nevertheless be defaulted with my current project .eslintrc (or could be my user’s .eslintrc).

If I set a ‘filePath’ in prettier-eslint I expect that only the rules defined there are applied and the others take default values. If this is how prittier-eslint should work then I think for this particular project this is causing lots of issues. But maybe you disagree?

I also tried to illustrate the issue by taking a screenshot of a breakpoint in the eslint/lib/config.js#getConfig() and printing the vector variable that contains more than one .eslintrc - the given one and another one that is in my local project - they are all merged and I think that shound’t happen

I just starting using pretties-eslint and is very very cool - will keep investigating the issue and try to pull request a solution - could take me a while since. But keep tit up !!! 😃

BTW - I’m developing a gallery of what code looks like using different popular eslint-configs here: https://cancerberosgx.github.io/prettier-eslint-gallery/gallery/

The idea is to compare eslint --fix with prettier-eslint and also (TODO) to generate reports of how well both formatters do the job fixing applying each the config

Versions I’m using :

node: 9.2.0 “babel-eslint”: “^8.0.3”, “eslint”: “^4.12.1”, “eslint-config-airbnb-base”: “^12.1.0”, “eslint-config-google”: “^0.9.1”, “eslint-config-gulp”: “^2.1.0”, “eslint-config-hapi”: “^11.1.0”, “eslint-config-mdcs”: “^4.2.2”, “eslint-config-standard”: “^10.2.1”, “eslint-config-walmart”: “^2.2.0”, “eslint-config-xo”: “^0.19.0”, “eslint-plugin-filenames”: “^1.2.0”, “eslint-plugin-hapi”: “^4.1.0”, “eslint-plugin-import”: “^2.8.0”, “eslint-plugin-jsx-a11y”: “^6.0.2”, “eslint-plugin-markdown”: “^1.0.0-beta.6”, “eslint-plugin-node”: “^5.2.1”, “eslint-plugin-promise”: “^3.6.0”, “eslint-plugin-react”: “^7.5.1”, “eslint-plugin-standard”: “^3.0.1”, “handlebars”: “^4.0.11”, “prettier-eslint”: “^8.2.5”,

[zimme]

Yes, they are related. But it’s because of the way we handle provided configuration and merge that with configuration we read from file.

I’ve been thinking about changing this behaviour, but it’s a breaking change so before we make that change I need to make sure the “new” solution can handle all the use cases otherwise the change seems unnecessary.

[zimme]

Closing this as it’s working as intended, i.e. we rely on eslint’s own config resolving and I won’t be implementing my own.