New: Add public APIs for config-arrays and file-infos

[manuth]

Summary

Allow 3rd-party developers to determine which configuration-files are considered by eslint.

Related Issues

• Add ConfigArrayFactory and CascadingConfigArrayFactory to the public API eslint#12631

[jsf-clabot]

All committers have signed the CLA.

[mysticatea]

Thank you for your proposal.

I agree that exposing ConfigArray is worthful, but I feel that this goal and this proposal is different a bit because ConfigArray doesn't have enough information for that. There are related files to configurations:

1. Config files
2. Shareable config files -- it's needed to re-run when we upgraded shareable configs.
3. Parser files -- it's needed to re-run when we upgraded parsers.
4. Plugin files -- it's needed to re-run when we upgraded plugins.
5. Rule files that --rulesdir option specified -- it's needed to re-run when we modified local rules.
6. .eslintignore -- it's needed to re-run when we modified .eslintignore.
7. The files that are imported by require("source") in the above files. -- it's needed to re-run if config files or other files imported other files and the imported files are modified.
8. The files of ESLint -- it's needed to re-run when we upgraded ESLint. This is a common case because ESLint is regularly updated every month.

The filePath property of ConfigArray contains 1., 2., and 6. But if we approve #9, it will contain only $CWD/eslint.config.js because all other files become "the files that are imported by require("source")." Therefore, I guess that the filePath property of ConfigArray will be not useful for this purpose.

If you want to get only 1., actually, it may be hard to distinguish if the filePath property of ConfigArray is 1. or not. Maybe true if the path is $CWD/** but not node_modules/**.

---

It's hard to know the files that are imported by require("source").

And Node.js has the cache for imported files. If we don't clear the cache, for example, when we updated plugin versions then the language server may use old plugin code partially and raise cryptic errors. Currently, we can clear the cache with require.cache, but if we started to use import("source") instead (it's required in order to support ES modules for plugins/configs) in the near future, we will lose the capability to clear the cache. Therefore, I think hard to re-run linting without restarting the Node.js process.

[manuth]

Humh...
I totally get your point - adding such a method to the public API, in this case, wouldn't add the desired ability of knowing which files to watch.

import {} from "source";, import "source"; and import var = require("source");, btw, affect require.cache as well so clearing or checking the cache would work out pretty well also for ES modules.

Anyway to reach the goal I'm after you'd have to import the plugins and settings and check require.cache for changes, right?

Sounds like this would require another separate method other than getConfigArrayForFile?

[mysticatea]

btw, affect require.cache as well so clearing or checking the cache would work out pretty well also for ES modules.

It's only if the "source" was CJS. If the "source" is ESM, Node.js caches it only in the internal cache and we cannot access it. The require.cache doesn't include imported ESM files.

Anyway to reach the goal I'm after you'd have to import the plugins and settings and check require.cache for changes, right?

Currently, ESLint doesn't support ESM, so it may work. However, after we supported ESM, it's going to not work properly.

Sounds like this would require another separate method other than getConfigArrayForFile?

Yes. I think getConfigArrayForFile is not useful for this purpose.

[manuth]

Alright - so cleaning the cache is of no use as it will stop working at some point anyway...?

Forking a new process might be of no use, too, as this would draw me unable to get the result from eslint... Or is there some way to pass JavaScript-objects from/to forked processes or any other alternative?

Yes. I think getConfigArrayForFile is not useful for this purpose.

Fine - shall we cover both the getConfigArrayForFile and the language-server stuff in this RFC?

[manuth]

@mysticatea is there something left to discuss?
I'm a little unsure whether or not to split this request up into 2 RFCs. What do you think?

[nzakas]

Given that we are now moving forward with #9, I don't think it makes sense to continue down this path of exposing more configuration details from ESLint.

If there's something that makes sense in #9 to expose for this purpose, you can certainly update the RFC to reflect this.