Config seems to be overridden with "diff:staged" everytime

[Diogosr6]

Since I updated to version 2.0.1 I get the error shown below where the git diff command doesn't recognise one of the options.

An unhandled exception occurred: Failed to load plugin 'diff' declared in '--config#overrides[0]': Command failed: git diff --diff-algorithm=histogram --diff-filter=ACM --find-renames=100% --name-only --no-ext-diff --relative --staged origin/master.. --
usage: git diff [<options>] [<commit>] [--] [<path>...]
   or: git diff [<options>] --cached [<commit>] [--] [<path>...]
   or: git diff [<options>] <commit> [--merge-base] [<commit>...] <commit> [--] [<path>...]
   or: git diff [<options>] <commit>...<commit>] [--] [<path>...]
   or: git diff [<options>] <blob> <blob>]
   or: git diff [<options>] --no-index [--] <path> <path>]

common diff options:
  -z            output diff-raw with lines terminated with NUL.
  -p            output patch format.
  -u            synonym for -p.
  --patch-with-raw
                output both a patch and the diff-raw format.
  --stat        show diffstat instead of patch.
  --numstat     show numeric diffstat instead of patch.
  --patch-with-stat
                output a patch and prepend its diffstat.
  --name-only   show only names of changed files.
  --name-status show names and status of changed files.
  --full-index  show full object name on index lines.
  --abbrev=<n>  abbreviate object names in diff-tree header and diff-raw.
  -R            swap input file pairs.
  -B            detect complete rewrites.
  -M            detect renames.
  -C            detect copies.
  --find-copies-harder
                try unchanged files as candidate for copy detection.
  -l<n>         limit rename attempts up to <n> paths.
  -O<file>      reorder diffs according to the <file>.
  -S<string>    find filepair whose only one side contains the string.
  --pickaxe-all
                show all files diff when -S is used and hit is found.
  -a  --text    treat all files as text.

After some testing it seems the problem is running the staged option alongside the ESLINT_PLUGIN_DIFF_COMMIT user defined option that can be seen above as origin/master...

Since I'm running the config "diff:diff" the "staged" option should not even be part of the git diff command. It seems to me that the problem lays on your side, but please correct me if I'm doing something wrong.

[paleite]

Thanks for reporting! It might be that you're using an older version of git. Which exact version of git are you running? Personally, I'm developing this plugin using git version 2.37.2.

[flupke]

I'm seeing the same error with latest git 2.37.3. The error appeared starting at eslint-plugin-diff version 1.0.16.

[flupke]

And I'm also invoking it with the ESLINT_PLUGIN_DIFF_COMMIT env var:

ESLINT_PLUGIN_DIFF_COMMIT=main.. yarn lint --config .eslintrc-ci-diff.js --color frontend/src/**/*.ts frontend/src/**/*.tsx

[quaardvark]

Had the same issue and there are 2 issues the plugin and diff/diff processor:

1. By default, diff/diff pulls mutual changes from both ahead and behind commits and runs ESLint on them. Most likely use case though, is that we we want to run ESLint only on changes introduced by ahead commits.
2. To work around the above issue ESLINT_PLUGIN_DIFF_COMMIT can be set to something like base_branch..., but this is not a valid syntax for git diff --staged, and because getProcessors function pulls diffFileList - it is run for all 3 processors during plugin init, regardless of desired processor, resulting in failure when staged processor is loaded.

I think a potential solution would be to only pull diffFileList inside processors, and not during plugin load.

[quaardvark]

My workaround was just to feed ESLint a narrowed down list of files with eslint $(git diff --name-only base_branch... -- | grep -E '\.(js|jsx|ts|tsx)$' | xargs) and use base_branch without dots for ESLINT_PLUGIN_DIFF_COMMIT. One caveat is that it will consider changed lines from both ahead and behind commits, but only in matched files, which is a viable workaround for me.

This plugin has performance issues when a large amount of files is thrown into ESLint pipeline to begin with, because of all the calls to git in pre-processor.