Feature request: allow CLIEngine.executeOnFiles consumers to skip globbing

The current implementation of CLIEngine.executeOnFiles accept an Array of glob patterns and resolve them. In certain situation API consumer might already know the exact list of file they want to lint and the globbing done by eslint could be skipped.

This is the case of xojs/xo for example, where we glob the files to lint, based on predefined patterns and ignore. We have to determine the list of file to lint, rather than just passing glob patterns to CLIEngine.executeOnFiles in order to implement certain features specific to xo.

As a result the files are globbed twice, once by xo, then once by eslint. The globbing done by eslint is redundant in that case as the file paths to lint are already determined and the ones to ignore are already excluded.

The proposed feature would provide a way to call CLIEngine.executeOnFiles with a list of paths rather than a list of glob patterns. When called this way eslint would process the file paths passed, skipping the glob resolution. This would result in a performance increase for users of tools consuming the eslint API.

I’m mentioning the case of xo as an example, but I believe it could be useful for other tools consuming the CLIEngine.executeOnFiles API.

As far as my test went, I think the change would be fairly simple, backward compatible and non obstructive for eslint.

CLIEngine.executeOnFiles could accept a second parameter, filePaths and

const fileList = globUtil.listFilesToProcess(this.resolveFileGlobPatterns(patterns), options)

would become something along those lines:

const fileList = (filePaths || []).map(filePath => ({filename: filePath, ignored: false})) .concat(globUtil.listFilesToProcess(this.resolveFileGlobPatterns(patterns), options));

Or instead CLIEngine.executeOnFiles could accept either:

• an Array in which case it would behave as of now
• and Object with a patterns and a filePaths property in which case the patterns would be handled as of now, and the filePaths as proposed above

In my very rough tests done on a test project with large amount of files the performance gain in the case of xo is around a 20% reduction in running time.

[not-an-aardvark]

This issue was accepted in today’s TSC meeting. However, there was consensus that the name of the option should be globInputPaths rather than glob, to clarify that other types of globs (e.g. overrides in config files, ignore patterns) are still resolved in either case.

[sindresorhus]

Should we have any special handling for glob: false and a path comes in that doesn’t point to a file, but might “look like” a glob? Should we consider printing out a warning in that case?

No, it’s explicitly set to no globbing. This is an API for ESLint consumers, not end-users.