Support passing individual files on cli so this can target staged files

[robross0606]

Tools like lint-staged and husky use the standard shell technique of passing a list of space-separated files against which to process. This allows it to run with commands like eslint, prettier or any other command that can take a list of files. However, copyright-header appears to only support the --include parameter which is regex.

Supporting this would allow copyright-header to be optimized for large repositories to run only on files which are staged as part of a precommit hook.

[robross0606]

While we're on the topic, supporting regex for include/exclude is a little odd. Typically, cli-based tools use glob pattern matching for file specifications.

[robross0606]

The more I dig into this, the more I realize there are just fundamental problems with the way this project targets files. This relies heavily on git ls-files but the problem is that the command is always relative to the current directory. So, let's say I have the file index.js in several locations in my project in various subdirectories. I've only changed the index.js file at the root of my project and that is the only one staged for commit. Attempting to run copyright-header doesn't work if I do this:

copyright-header --fix --copyrightHolder "My Company" --include "./index.js"

Nor does escaping the regex work:

copyright-header --fix --copyrightHolder "My Company" --include "\./index.js"

Because git ls-files doesn't include the ./ at the front to specify location from root so matches are never made. But doing this doesn't work right either:

copyright-header --fix --copyrightHolder "My Company" --include "index.js"

Because you're applying regex pattern matching instead of glob which is designed for file matching. So matching index.js matches all the other index.js files in the project even if that is not the intent of the cli operation. Because of this, I'd highly recommend either changing how --include and --exclude work in a breaking major version change, or --include-glob and --exclude-glob options as new features.

Also not sure why you're manually parsing a comma separated list of strings as a single string instead of using Commander's variadic option. This is most likely why you're getting other support tickets with people confused about how --include and --exclude work. They do not work like most command-line options work on other tools.

[robross0606]

Yet another issue is that git ls-files always works with Posix paths, but people may be supplying Windows paths on --include and --exclude. At the very least, this should be a documented requirement that all paths are supplied in posix format.

[robross0606]

What you could do is post-process git ls-files slightly to prepend ./ on each entry. So, instead of matching against this list internally:

index.js
src/stuff/index.js

You would be matching against this:

./index.js
./src/stuff/index.js

This would then allow people the flexibility to specify --include and --exclude with specificity relative to the root. Still not as flexible as using glob pattern matching, but serviceable. Then this would work:

copyright-header --fix --copyrightHolder "My Company" --include "\./index.js"