Support for incremental scanning of files (only scan the files that were modified since last run)

Running eslint thru a large code base takes something about from 6 to 8 seconds (depending on the amount of code in the files and how bad the code is in the first place)

Using a cache layer that remembers that files were not modified since last time they were considered valid hugely reduces the amount of time that the process take, depending on the number of files modified.

On a regular basis for a given feature only a handful of files are modified so having a way to execute the tool only on those files might save some time.

I have written a cli wrapper over eslint that does that, but having that into the eslint module would be really nice:

This is an example of the tool executed over one of the folders of the project

# first run will take as much time as normal
eslinter 'src/**/*.js' 

>> config: .eslintrc
>> cache: true, format: eslint-friendly-formatter
>> Total files: 255, files to process: 255
>> Eslint validation complete. No errors found
>> time it took:  6539ms

# second and subsequent execution will operate only on changed files
eslinter 'src/**/*.js' 

>> config: .eslintrc
>> cache: true, format: eslint-friendly-formatter
>> Total files: 255, files to process: 4
>> Eslint validation complete. No errors found
>> time it took:  292ms

So as you see actually know which files changed makes a difference in the time it takes

[royriojas]

@dawsbot not sure I understand your question, but Eslint does support storing the cache in external locations.

Caching:
  --cache                      Only check changed files - default: false
  --cache-file path::String    Path to the cache file. Deprecated: use --cache-location - default: .eslintcache
  --cache-location path::String  Path to the cache file or directory

[IanVS]

That’s an interesting point. If the file hasn’t changed, it seems like we should be able to use the results of the previous cached run, regardless if there were errors or not. The only files that really need to be linted are new files and files that have been changed. I think the proposal should probably be its own issue though, as this is an old, closed issue. Would you mind opening a new one and tagging me on it, @galvarez421?