Global config that does not define StylesPath results in error with FindAsset

[StaticRocket]

Check for existing issues

• Completed

Environment

• Linux
• Go (local build)
• vale version v3.14.1

Describe the bug / provide steps to reproduce it

1. Using a user global config ($HOME/.config/vale/.vale.ini) and a project local config ($PWD/.vale.ini)
2. Define StylesPath in only the local configuration
3. Attempt to load an external style with a custom dictionary (RedHat for example)
4. The following error will be reported:

E201 Invalid value [.github/styles/RedHat/Spelling.yml:1:1]:

   1* ---
   2  extends: spelling
   3  level: warning

unable to resolve dicpath

Execution stopped with code 1.

FindAsset will be given the last cfg.Path in the list, which will not exist as it's a combination of the global config path with the local StylePath.

The way paths and configuration structures are handled right now is a little problematic. Paths should be expanded relative to the INI file before INI shadowing takes effect.

[StaticRocket]

What's the actual intended behavior of the config mechanism right now? Is the global config supposed to:

1. Be the "default" with the local config overriding keys with local values
2. Be merged into the local config, extending lists but potentially ignoring simple key-value pairs
3. Be a fallback only loaded if a local config doesn't exist

I can see some merit to all 3 different behaviors, but currently I've seen comments that conflict.

I'd expect projects using this tool with their own dictionaries wouldn't want some user dictionary masking spelling issues, hence why I kind of want to enforce loading the global config only if the local config isn't found.

[jdkato]

The intention was to allow users to make their own customizations to existing project configurations without having to touch the source for that project. In other words, maybe they have their own style they want to inject or disable certain rules, etc. See the docs for more.

I don’t see it as a concern of the upstream projects because, independent of what their users choose to do locally, the project configuration will be enforced at any CI level.

[StaticRocket]

Hm, suppose I'm concerned that user global rules could mask things before submission. If upstream enforces the CI comments then that's an extra cycle that could have been avoided if we didn't load user configurations.

Guess that's not really a concern if it's purely additional in the case of what styles are allowed. Just things like overriding the default level, adjusting style rules that are dictated locally, and adding dictionary values seem a little problematic.

[StaticRocket]

Like ideally, the user global configuration would always cinch down on an existing project config. Allowing the user to loosen restrictions seems a little problematic.

[jdkato]

I really don’t see it that way: you’re asking for the ability, as an upstream project, to be able to control what I do as a contributor on my own local machine.

It’s a feature that allows users to modify their own local experience (often in, say, VS Code).

[StaticRocket]

If it isn't being done explicitly through configuration then it's still being done implicitly through CI or reviews

[StaticRocket]

But sure, if this is intended functionality then there's really just one bug. Paths need to be expanded based on INI location at the time they are parsed. I'll look into that tomorrow.