Request: Extract config loading into a separate module

What version are you using? 3.7.1

What did you do? Checked the source code to figure out what module you used to load config for a file (walking up the file tree), verify it, apply defaults, etc

What happened? Found out that the code for it is part of this repo (mostly https://github.com/eslint/eslint/tree/master/lib/config and https://github.com/eslint/eslint/tree/master/lib/config.js)

What did you expect to happen? That it was at least somewhat an external module which could be reused in other projects

My request would be to extract it so that I could reuse the logic in a project I’m working on (https://github.com/SimenB/stylint).

The API I’d roughly want would be to provide a file path, and have the module return a normalized config object from looking at some file for config (.eslintrc here), apply options provided there (in the current eslint format), walk up the tree until root of FS or root: true (maybe checking package.json along the way), making sure it’s normalized. Then return the whole thing. An awesome addition would be to actually apply defaults before invoking the rule, instead of making the rules themselves handle defaults. Not sure how plausible that is though (considering you haven’t done it yet)

I’d be willing to work on this, and provide an initial implementation, but if the extracted code could still be part of the ESLint org, that would be awesome! And if you’re not interested, I’ll extract a subset of what I need, instead of “wasting time” making it into a generic module

I tried asking on Gitter but didn’t receive any response.

[nzakas]

I’m not sure I really want to go down the path of separating out file/glob stuff at this point. Those are both so small and with some pretty poorly thought-out APIs that I don’t know that it’s worth the trouble to explore splitting those out too much. You can feel free to open an issue if you feel strongly, I’m just less convinced that the overhead of maintaining those separately is as useful as potentially maintaining a config loader separately.

For this issue, what I think would be easiest to put together design-wise is to propose an interface (maybe use TypeScript or Flow notation so it’s code rather than words), and then provide some further detail as bullet points. Then, give some example code about how you’d see it being used within ESLint itself and explain what code we could get rid of (config.js?) or where various bits of functionality would move.

For instance, I’d really like to get all config-related stuff into the lib/config directory, so getting rid of config.js and adding lib/config/config-loader.js would be a good direction. Are there further pieces of config.js that can be split out into config-file.js and config-ops.js (that was the first refactoring I did)? Or would it make sense to add another utility file for some of what’s in config.js?

[nzakas]

@SimenB sorry your PR hasn’t had much activity - this project is incredibly active and everyone is working in their spare time trying to do their best, so less controversial things tend to get prioritized over others so we can keep the project moving forward. You also flagged your PR as “WIP” and didn’t give much context

I’m a bit concerned about the scope of the changes you keep introducing to this thread, so I’d like to suggest some small, intermediate steps instead. Rather than thinking about how to split out pieces of the ESLint project into independent pieces, let’s focus on what a ConfigLoader could look like inside of the project as a refactoring plan. If we can figure that out, then we can go the next step and see what it would take to abstract out things that are specific to ESLint.

I’d also like to ask that we keep the discussion on this issue narrowly focused to that one goal. Other small changes should be handled on separate issues. I’d also recommend not submitting a PR first, but rather doing some due diligence and proposing an API that might make sense.