It's not entirely straight forward because.shellcheckrc files are per-file while the formatter options are per invocation.

For example, you can do

echo "disable=SC2034 # Don't warn about unused variables" > lib/.shellcheckrcecho "disable=SC2016 # I know how to use single quotes" > bin/.shellcheckrc

and thenshellcheck */*.sh will apply the correct rules to the correct files.

Thecolor option currently does not support being applied to some files but not others, and if you were to extend this towiki-link-count I'm not sure what it would mean for one file to say 0 and another to say 5.

Alternatively, making sure auto 'always' works is an option :p

but in seriousness, I do like having options stored in a per-repo level. I think it should just traverse in the tree though, right? so global, trumps user, trumps root, trumps folder setting. So if you have it in your local rc, but not anywhere in the repo; you get it.

I suppose one could argue on the directory vs root level; it could be that 'note, some settings, regardless where they are set, are applied to the repo as a whole, when asking shellcheck to auto-scan for files, if this is undesiresd invoke shellcheck on a 'per file' basis' and there, it should favor local settings over root settings?

IMHO, this really belongs in an environment variable (FORCE_COLOR=1 andNO_COLOR=1). It's easier to forcefully enable/disable colour support for a process this way, and users typically do so cognisant of where/how output is being rendered; e.g.,an Emacs buffer or pager likeless(1) will want consistent colouration behaviour regardless of a project's local configuration.