https://github.com/not-an-aardvark/eslint-plugin-prettier
It allows you to:
eslint.eslint --fix.I like it because it means that you can just stick with the existing ESLint tooling. That's pretty great. I need to give it a shot. One thing I like about prettier-eslint is it can configure prettier based on the eslint config. Because with eslint-plugin-prettier I could configure the plugin differently from the rest of my config. But I need to give this a closer look. I would love for us to converge on a single solution for this.
One thing I like about prettier-eslint is it can configure prettier based on the eslint config.
Ah, I see, prettier-eslint looks at eslint's options! For example, it looks at the good old "quotes" eslint rule to decide if prettier should use double or single quotes. That's pretty cool, I didn't know that before! (Though in my project, I've only enabled non-stylistic lint rules.)
Actually, that seems like a pretty good solution. Just don't configure things with ESLint that prettier can handle. Let me take a chance to use your plugin on my stuff. If I like it then I'll deprecate this package and recommend people use yours. Sound good?
Yes, it sounds like a good plan. Just note that I didn't make the plugin, @not-an-aardvark did (thanks!) :)
Trying it now and one major issue I have is I'm getting:
Follow
prettierformatting (expected ';' but found '\n').
Because I prefer to avoid semicolons. @not-an-aardvark, I think that the goal of prettier-eslint is to allow you to use prettier for prettier is good for and eslint for what eslint is good for. Meaning that prettier formats things and eslint lints things. I would prefer to not get linting errors from prettier and only get the autoformating features. Is that something that eslint-plugin-prettier can do?
Ah, I didn't think of that use case. Looks like both tools have reason to exist, then! (Because I doubt that will be doable in eslint-plugin-prettier).
Well, if @not-an-aardvark can agree to allow configuration to disable error reporting from this plugin, then we could do away with my module. Otherwise, yes, I think they should both exist to support the different use cases.
Otherwise, yes, I think they should both exist to support the different use cases.
I agree. I think the best use case for eslint-plugin-prettier would be to only enable the eslint rules that report a pattern in the AST (e.g. requiring curly braces around if statements), and to disable all the eslint rules that don't touch the AST (e.g. requiring semicolons). Then prettier can pretty-print the AST, which avoids conflicts since prettier doesn't actually make any changes to the AST.
If you want to use prettier but your desired code style has formatting that differs from what prettier would output, I think using something like prettier-eslint is probably still the best solution. I think the ideal solution would be for prettier to add an option for semicolons.
Sounds good. I'll go ahead and reference your project in the README with that note. Great work team :)
Would be nice to summarize the differences between the two tools:
eslint --fix as way to get formatting options not existent in prettier. For people who "disagree" with prettier's output.Makes sense? (The wording of course needs to be improved.)
I like it. @lydell, do you want to do contribute that? Please make sure to follow the contributing guidelines.
Yes, I'll send a PR soon!
Most helpful comment
Well, if @not-an-aardvark can agree to allow configuration to disable error reporting from this plugin, then we could do away with my module. Otherwise, yes, I think they should both exist to support the different use cases.