Support for global config

[bernabas]

I am trying to exclude a file without having to list it in the repo's standard.yml file. That directory is included in my global gitignore file so it gets to be ignored, and I do not want to add it to the repo's standard.yml file exclusion list (for the same reason why I added it to the global gitignore file vs the repo's gitignore file).

This PR adds that basic functionality by looking for a .standard_global.yml file in the home directory.

[searls]

Hi @bernabas, I can definitely understand what you're going for here, even though it's a pretty niche edge case. I have two concerns:

1. With this feature, someone could have a standard_global file that results in Standard passing/skipping files unexpectedly, such that things look green locally then they push and break the build. I don't think many test runners have similar features for similar reasons, that having an outside-the-repo/global way to make your machine behave differently from all the others undermines the veracity of the tool's results. Before considering this feature, I'd first take pains to make sure that the same result can't be achieved in other ways like (ideally) command line flags or local edits to your .standard.yml file

2. Dumping dotfiles in a home directory makes a lot of assumptions and is increasingly frowned upon. I'll lean on my resident dotfiles czar, @jasonkarns to explain why

[jasonkarns]

So if we supported this, IMO, it would need to follow the XDG basedir spec. Which means the global file would live at ${XDG_CONFIG_HOME:-$HOME/.config}/standardrb/config.yml or similar. (That addresses 2.)

There is some prior art that addresses 1.
Rubocop supports a global config file, but the presence of a local file takes precedence. So a global standard config would not be used if a local config existed. This avoids "works on my machine" false negatives.

Eslint also supports global configs and actually does combine the global config with local configs. This exposes them to the inconsistent behavior we're concerned about. Their solution to this is for the local config to specify root: true in a local config to stop the upward hierarchy lookup. This approach is useful in that it allows per-subdirectory config files, but I wouldn't recommend this approach at all. (I'd imagine that as projects mature, it becomes increasingly likely to find a root: true in every local config, thereby effectively behaving the same as rubocop.)

So, I would be in favor of this feature provided:

• we respect XDG
• the global config is only referenced in the absence of a local config

Unfortunately, I suspect this latter requirement makes the feature moot for @bernabas' use-case?

[searls]

I'm becoming more sympathetic to this for exactly one edge case: ignoring particular untracked files that you don't want Standard to touch. I find myself making a lot of scratch files that I want my tools to skip and which (because I'm not committing them) I don't want to have to reference from tracked files that configure my tools.

If I'm debugging something in the project with a throwaway foo.rb driver script and I don't want Standard to operate on it for whatever reason, it'd be nice to have an equivalent to global core.excludesFile gitignore to allow for that

All that to say, and I realize this isn't the thrust of the implementation of the pull request, but it might meet the spirit of what @bernabas was going for.

[jasonkarns]

Personally, I'd rather be able to tell standard to only look at versioned files. Then standard doesn't need to care why or how the files are unversioned. Instead, it would ask git which files are versioned, and only scan those. (Not surprisingly, if this were how Standard worked, it would eliminate the need for all but one or two standard's built-in ignore rules.)

[searls]

That thought occurred to me too, but unfortunately such an option would have the unintended consequence of not linting/formatting any new files until they were committed. Meaning every time you write new classes you wouldn't benefit from autoformatting until committing them. And once committed you'd likely discover they have linting errors. 🤔

[jasonkarns]

From the cli I suppose. But IDE integration would still be in effect and run against new files.

[searls]

Our VS Code extension reads the config and ignores ignored files, though :-/

[jasonkarns]

Hmm. Seems weird. Vim passes the source to the tool, iirc.I would have expected LSP to take source directly from buffer and not think about “files”. Bummer