Error: reportUnusedDisableDirectives
must be any of "error", "warn", "off", and null
#802
Labels
reportUnusedDisableDirectives
must be any of "error", "warn", "off", and null
#802
Versions:
prettier-eslint
version: v15.0.1node
version: v16.18.0npm
(oryarn
) version:pnpm
v7.18.4Have you followed the debugging tips?
Yes
Relevant code or config
.eslintrc
What I did:
I set
reportUnusedDisableDirectives
option totrue
and ranprettier-eslint
viaprettier-eslint-cli
.What happened:
Reproduction repository:
https://github.com/qyurila/reprod-prettier-eslint
Problem description:
The property
reportUnusedDisableDirectives
should be boolean. What must be "error", "warn", "off", or null is one of API options which has the identical name.If
reportUnusedDisableDirectives
is set to "error", null or something, not only ESLint throws an error but alsoprettier-eslint
does not fix any ESLint rule triggered.This problem prevents the use of any ESLint config package that contains
reportUnusedDisableDirectives
(e.g.eslint-config-xo
), because no matter what type of value is overwritten toreportUnusedDisableDirectives
there are still be a problem that makes it unusable. It's urgent to me because I cannot usevs-code-prettier-eslint
for my project until the main repo gets fixed!Suggested solution:
Separate
ESLintOptions.overrideConfig
from otherESLintOptions
propertiesActually, I made a PR about this issue a while ago (#798), but I came out with a more reasonable solution and I thought there should be a discussion about the implementation so I'm creating this issue.
#696 made some ESLint config options that changed in ESLint v8 to be manually moved inside of
overrideConfig
to "lessen the upgrade overhead". I don't know if there wasreportUnusedDisableDirectives
option at that time, but anyway, the patch requires a change now because of this option which has an overlapping name. It seems there is no desirable solution that follows the current method because that will eventually make one of the options not configurable.Given that, I think it would be good solution that adding new
eslintOptions
option toformat.option
and moveESLintOptions
to it exceptESLintOptions.overrideConfig
. That's becauseeslintConfig
was named and documented as it accepts ESLint configs, but no other options (e.g.fix
,useEslintrc
). So creating anotherformat.options
for them makes more sense.Also, it's notable that the proper documentation would be followed, which is actually good because there are kinds of
ESLintOptions
supports already despite no clear mention of it in docs.Another (and I originally PRed - #798) solution would be creating a new property
apiOptions
forformat.options
. It requires a bit fewer changes than the above solution, but I don't think it's clearly better. You can see how this implementation would look like if you want.What do you think about it?
The text was updated successfully, but these errors were encountered: