support disabling specific ESLint rule fixes #413
Comments
|
There are several ways to use prettier-atom + eslint together. Are you using the "ESLint Integration" option? This uses prettier-eslint under the hood, so we'd need that repo to support this option before we could make any changes here. As an alternative, if linter-eslint is working well for you, I would look into running prettier as an eslint rule. Then you could just turn prettier-atom off for that project and it should work I think. |
|
@robwise thanks for quick response!
Yes
|
|
Yeah with the I would need an API from that package that allows disabling of fixing certain rules in order to reimplement what linter-eslint does. In other words, prettier-atom isn't directly talking to eslint the way linter-eslint does, instead, we are going through a middleman (prettier-eslint) and they need to expose this ability to us.
Yes, then I would definitely check out running prettier as an eslint rule and just turn off prettier-atom entirely. This may turn out to meet your needs exactly. Alternatively, you can ask prettier-eslint to expose this ability and we can implement something similar to linter-eslint on prettier-atom. |
|
I'd be up for running prettier as an ESLint rule but what about other files, like MD or JSON or all others that prettier formats but ESLint doesn't understand? Will they be cleaned as well via ESLint? |
|
No, that's a good point, you could also try blacklisting the JavaScript files in prettier-atom so that linter-eslint takes over for those, but you still have prettier-atom for everything else. Like I said though, I'm happy to add this option to prettier-atom if you can convince the prettier-eslint guys to support it in their API. |
|
Wow, blackisting I'd say let's keep this issue open? Because the problem is there on the promised solution to users (advising to disable |
|
Yeah for sure, I'm glad you got it working finally but it definitely would be easier if we could have an option like linter-eslint. Can you make an issue over at prettier-eslint to get that option added to the API? Otherwise my hands are tied because everything is going through that package before it gets to ESLint. |
revelt
mentioned this issue


When I was using only ESLint Atom plugin

linter-eslint, it had this preferences setting where I could stop it from removing my.onlytests from AVA unit tests:This meant that any occurrences of
t.onlywould get flagged as errors and husky precommit hook would call ESLint and block the commit.Now I switched to Prettier and Prettier doesn't have a setting to block the automatic fixing of ESLint issues. My AVA tests'
t.onlygets removed upon saving:This means, I have to either turn off the rules
ava/no-only-test&ava/no-skip-testcompletely (but I risk myt.onlyies spilling into the production code) OR turn on and off Prettier when sorting out unit tests (which is tedious).Before you say it's ESLint problem not
prettier-atom'seslint/eslint#7549 was closed (imho short-sightedly). Furthermore,
linter-eslinthas nailed this already, they added a field which lets you whitelist the rules to stop auto-fixing. It even works with Prettier turned off. It's just a matter for Prettier to mirror the setting in its own GUI field inprettier-atom.Before you say it's Prettier's problem not
prettier-atom'sCorrect me if I'm wrong, but in Atom+ESLint+Prettier setup, there are only two setup locations:
eslintrcor this plugin's config window in Atom Preferences GUI. If the former is out, this leaves us only latter. Which means, you will have to add some sort of a field in preferences GUI... of this plugin, not Prettier's.Proposed solution
As @not-an-aardvark suggested in eslint/eslint#7549 (comment), you can do that in command line:
If we could somehow add a settings field in GUI, same like ESLint's:
and wire it up to the place where Prettier actually calls ESLint
fixfunction, to pass in the ignored-for-fixing rules, that could be the solution?PS. It's perplexing why has nobody had this issue yet — are guys not using Prettier or Atom or AVA unit tests? We're many months into this setup, all components are not new anymore... Yet I can't find anybody complaining about this... {end of rant}
The text was updated successfully, but these errors were encountered: