Closed nzakas closed 4 months ago
I'm wondering if we need this project anymore, because eslint
+ eslint-plugin-eslint-plugin
could be able to do the same.
https://github.com/eslint-community/eslint-plugin-eslint-plugin/issues/398
Maybe, but creating a dependency on ESLint in order to fix plugins that aren't working in ESLint might cause issues. I think updating this tool to have something standalone is beneficial at least in the near term.
eslint
and eslint-plugin-eslint-plugin
would only be dev dependencies. I believe most if not all plugins already have eslint
as a dev dependency, and a lot of plugins already use eslint-plugin-eslint-plugin
(and eslint plugins should generally be using eslint-plugin-eslint-plugin
anyway). In any case, they could use them as a one-time tool to fix the code and then uninstall them.
But okay, I'm not opposed to updating this tool as well.
We should also update references to the methods listed in this section
How should we handle context.getComments()
in the codemod? Since SourceCode.getComments()
was removed in v9. Should we just log a warning and link to docs?
We should create a codemod that applies most of the changes mentioned in the blog post about changes to the rule API. Primarily changing:
context.getScope()
context.markVariableAsUsed()
context.getAncestors()
context.getDeclaredVariables()
For each of these, we should be creating backwards-compatible code such as:
We should also update references to the methods listed in this section
If we find a reference to
CodePath#currentSegments
, then the best thing to do is output a warning stating that it can't be fixed automatically and point to this section.(It probably can be fixed automatically but would be pretty complicated. If we get enough requests then we can revisit.)