Expose cache class and allow to inject it

The version of ESLint you are using.

eslint v5.4.0

The problem you want to solve.

Hi eslint team 👋

I’m the maintainer of eslint_d which aims at accelerating eslint, especially when used frequently on single files, e.g. as an editor plugin.

Looking at the eslint cache implementation, it strikes me that the eslint_d background server could keep an in-memory cache instance, making it obsolete to read and write the cache file. To support this, I would need slightly more control over the cache.

Your take on the correct solution to problem.

My suggestion is to expose a cache class and allow to inject instances as an option for the CLIEngine. If the cache is injected, it would be the callers responsibility to persist the cache.

If you’d consider changing the API for this, I’m happy to contribute a pull request.

Thanks for making eslint!

[mantoni]

Regarding @not-an-aardvark’s last question: executeOnFiles(pattern) receives a pattern which is then resolved to a list of files. Therefore the roundabout way of doing things. Since I’m trying to be 100% eslint compatible, I wouldn’t want to expand patterns myself. We could expose that separately though, e.g. engine.listFilesToProcess(pattern). With the normalized file list, I might even be able to implement my own results caching without touching the eslint core cache implementation 🤔

EDIT: Just noticed that resolveFileGlobPatterns does exactly that. 2nd edit: I got confused. This does something else.

[not-an-aardvark]

Thanks for working on this!

I’m hesitant to add something like engine.createResultCache or the ability to inject a file-entry-cache instance, because it seems like would lock us into using file-entry-cache’s API indefinitely. In the future, it’s possible that we will want to change the cache file format and/or use a different library with a different API. My impression is that the “injection” approach would be easy to implement in the short term but would cause problems in the long term by exposing term because it would expose too much API surface and prevent us from changing the implementation.

To me, it seems like it would be nice to have the API look vaguely like this:

const engine = new eslint.CLIEngine(
    {
        cache: {
            getUpdatedFiles(files) {
                // returns a list of updated files
            },
            updateCache(changesToCache) {
                // makes changes to the cache
            }
        }
    }
);

Then CLIEngine would call the provided getUpdatedFiles and updateCache methods while running in order to get data from the cache.

• With the --cache flag, the default behavior would be for getUpdatedFiles to read .eslintcache and check the mtime, and for updateCache to write an .eslintcache file to the filesystem, as it does now.
• Without the --cache flag, the default behavior would be for getUpdateFiles to assume all files are updated, and for updateCache to be a no-op. This would be the same as the current behavior when running without a cache. However, it would remove some complexity from CLIEngine#executeOnText because it would no longer be necessary to have special logic for the --cache flag – the difference in behavior would be encapsulated in the different getUpdatedFiles and updateCache methods.
• eslint_d would provide a getUpdatedFiles method that reads information from memory, and an updateCache method that writes to memory.