Versions:
prettier-eslint version: 8.8.2node version: 8.11.1yarn version: 1.5.1Have you followed the debugging tips?
Yes
Relevant code or config
.eslintrc.js
const path = require("path");
const config = {
parser: "babel-eslint",
env: {
node: true
},
plugins: ["import"],
rules: {
"import/order": [
"error",
{
groups: [
["builtin", "external"],
"internal",
"parent",
["sibling", "index"]
],
"newlines-between": "always"
}
]
},
settings: {
"import/resolver": {
node: {
root: __dirname
},
alias: [["appalias", path.resolve(__dirname, "src/app")]]
}
}
};
module.exports = config;
src/example.js (file being formatted)
const fs = require("fs");
const main = require("src/main");
const app = require("appalias");
const packageJson = require("../package.json");
const mainSibling = require("./main");
What I did:
Run yarn prettier-eslint --list-different --write src/example.js.
What happened:
It removes the empty line between const main = require("src/main"); and const app = require("appalias");. This causes an eslint error.
Reproduction repository:
https://github.com/amosyuen/prettier-eslint-import-empty-line-removal
Problem description:
Seems that the eslint --fix run by prettier-eslint doesn't handle the import/order rule correctly. When running with trace logging it looks like import/order rule is correctly set in the inferred options and that prettier doesn't change the empty lines between import statements. However, for some reason the output after eslint --fix will remove the empty line, causing an eslint error.
Running yarn eslint --fix src/example.js will correctly add back the empty line. So there seems to be something wrong with how prettier-eslint is running eslint. I also made sure I used the same version of eslint.
How is prettier formatting the file if you just run prettier on it? I'm thinking that becuase prettier runs first and if it is removing the empty lines between the imports then eslint, which runs after, isn't able to add an empty line again.
Edit:
My bad, I didn't read close enough... This is weird...
I created some simple code to use the eslint CLIEngine and the problem repros there. So maybe this is an eslint issue.
That's even weirder as eslint's cli uses the CLIEngine, but if you can reproduce it with just CLIEngine it seems like an eslint issue :+1:
Cross posted to eslint https://github.com/eslint/eslint/issues/10567
So after some back and forth on the eslint bug I think it's a bug in prettier-eslint. Seems that prettier-eslint is passing the eslint config directly into the constructor for eslint CLIEngine, but those options don't support all the same fields as eslintrc. The eslint documentation https://eslint.org/docs/developer-guide/nodejs-api#cliengine doesn't list the settings field, which would explain why my eslintrc settings weren't respected.
Instead the options should be passed in like new CLIEngine({ configFile: elintConfigOptions }), or alternatively just use default settings which will use the default eslintrc.
Thank you for all the work tracking this down.
The reason we need to load the configs ourselves and give it to eslint is that we turn off some eslint options if remember correctly.
Sorry, I didn't actually test my above comment, and went off of what the eslint guy was saying. But it seems like configFile option only allows using a file path. So right now there is no way to dynamically pass in settings to CLIEngine it seems.
This is an old task, but we are experiencing this with our setup now which is very similar to the config in the initial bug report. ESlint expects the space that Prettier removes.
We鈥檙e having problems with this as well in our team.
Stale issue
having this issue with prettier API directly now, no eslint involved
Most helpful comment
We鈥檙e having problems with this as well in our team.