Code structure of "utilities" is inconsistent

The modules that CLIEngine or Linter depend on are sometimes stored in inconsistent locations (at least, it seems that way to me).

At this point, it can be hard to see a consistent difference between files stored in lib/, vs files stored in lib/util/. That is, in both directories, we can see both “core” and “utility” modules. I would like to see if we could store only “core” modules in lib/, and only “utility” modules in lib/util/. (The rule of thumb I would use for what constitutes a “core” module is as follows: Anything important enough to document in our Node.js API documentation page, or anything directly called by CLIEngine or Linter that performs a key piece of linting, should probably be “core” and should probably be in lib/.)

I think it could help new contributors find their way around the codebase better if we try to be more consistent about placing core modules in lib/ and utility modules in lib/util/.

Some examples of modules that I think should be moved from lib/ to lib/util/:

• lib/ast-utils.js: This is used by many rules, but it is not a strategic part of our API. I think this should be in lib/util.
• lib/file-finder.js: This is used in the config file operations for helping find files on the filesystem. Config APIs themselves (e.g., in lib/config.js) should be “core” and be in the lib directory, but I think this file should be in lib/util.
• lib/logging.js: This is clearly not a core module, but rather something used for internal logging only. Should be in lib/util.
• lib/timing.js: This is clearly not a core module, but rather something to help with performance testing only.

(I do think there could be other modules on this list, especially around rule management, but this is a good start.)

Some examples of modules that I think should be moved from lib/util/ to lib/:

• lib/util/rule-fixer.js: This API is used in all core and custom rules that support autofixing, which is a key component of the linter.
• lib/util/source-code-fixer.js: This code is a key part of tracking and applying autofixes, which is a key component of the linter.

---

Would love to get feedback from the rest of the team on this.

[aladdin-add]

what about lib/ast-utils.js => lib/util/ast-utils.js? if so, all utils will be in lib/util/ dir.

and personally I’d like to rename ast-utils.js => ast-util.js, so it could be consistent to other util, like npm-util.js, path-util.js.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that accepted issues failing to be implemented after 90 days tend to never be implemented, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.