Expose ast-utils in the api
See original GitHub issueThe version of ESLint you are using. 6.x
The problem you want to solve. In order to customize some rules for our specific use cases, the eslint team has at times suggested forking a core rule or creating our own. Most of the core rules us the ast-utils module internally.
In order to fork these rules, we either need to fork ast-utils.js as well, or require the module by reaching deep into eslint codebase. In order to keep maintenance down on our plugin, we decided to go with the second route and require the file from the eslint code.
When upgrading to eslint v6.x from v5 we found that our plugin broke because the file was moved internally.
In addition to the problem with forking rules, this module would be very useful for creating custom rules, as the team put a lot of work into these very useful helper functions.
Your take on the correct solution to problem.
If these, and possibly other utilities, were exposed in the api export itself we could simply require the eslint module and use the ast-utlis
property. (i.e. require('eslint').astUtils
or similar)
Are you willing to submit a pull request to implement this change? Yes
Issue Analytics
- State:
- Created 4 years ago
- Reactions:5
- Comments:10 (6 by maintainers)
Top GitHub Comments
I think this would be a nice thing to have. I’ve started a repository here and plan to copy over general utilities (though at this point there’s no guarantee they’ll work with anything but ASTs that follow the ESTree spec).
I agree. ast-utils were never meant to be public. I would highly suggest somebody copy and refactor them into external package if needed, since this package might be useful for other purposes as well (babel, etc.)