Option to disable global config file

[alecthegeek]

According to the docs the global config is always read last and can override any settings in the project config file.

This seems like a bad thing when projects want to ensure consistency across all workstations and environments.

Would a GlobalConfig = NO option be useful? It would skip looking for the global file.

[jdkato]

The global configuration file is intended to be a place for users to be able to apply their own rules independent of the configuration of any specific project.

I wouldn't want a project to have the power to disable my personal configuration. Similarly, my personal configuration choices wouldn't show up at the CI level of a project.

In other words, I think the decision to use (or not) a global configuration should be made at the user level, not the project level.

[alecthegeek]

We have a difference in working culture I suspect. I want folks to get the CI experience on the workstation, enforced by githook scripts. That way they can fix problems straight away, instead of waiting 10-n minutes for a notification from the CI pipeline. Can we fake this feature by setting the VALE_CONFIG_PATH to some value? Alec Clews Personal ***@***.***> Melbourne, Australia. Blog:https://alecthegeek.tech PGPKey ID: 0x9BBBFC7C

…

On Tue, 12 Nov 2024 at 10:08, Joseph Kato ***@***.***> wrote: The global configuration file is *intended* to be a place for users to be able to apply their own rules independent of the configuration of any specific project. I wouldn't want a project to have the power to disable my personal configuration. Similarly, my personal configuration choices wouldn't show up at the CI level of a project. In other words, I think the decision to use (or not) a global configuration should be made at the user level, not the project level. — Reply to this email directly, view it on GitHub <#921 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADNM52BTPRMHLYGBAQUZL2AE2FPAVCNFSM6AAAAABRSUV6S2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRRHE2TQMI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jdkato]

I'm really not sure that I understand the issue.

Just so we're clear on how this works: Vale configuration files aren't one or the other. Configuration is loaded in a cascading fashion, allowing for multiple sources to contribute.

For example, let's say a user is working on two projects with distinct configuration plus their own global configuration.

• When they're working on project 1, the local experience will project 1's configuration + their personal config.
• When they're working on project 2, the local experience will project 2's configuration + their personal config.

I want folks to get the CI experience on the workstation, enforced by githook scripts.

Assuming such a workflow, the only way that something would break here is the following scenario:

1. Someone creates a global .vale.ini file;
2. they deliberately disable a project rule;
3. they push content that violates the specific rule they chose to disable.

On the other hand, there are many ways that people could use a global .vale.ini file to customize their local environment without breaking the "CI experience."

Can we fake this feature by setting the VALE_CONFIG_PATH to some value?

No, the global configuration file doesn't exist by default, so you have to opt-in to its use. If someone chooses to do so, any given project doesn't have the power to disallow them to do so.

[jdkato]

If someone chooses to do so, any given project doesn't have the power to disallow them to do so.

This actually isn't strictly true. While you can't do this generally (i.e., for CLI or text editor use), you could do it in a Git Hook by passing the --no-global flag when calling vale.

[alecthegeek]

If someone chooses to do so, any given project doesn't have the power to disallow them to do so.

This actually isn't strictly true. While you can't do this generally (i.e., for CLI or text editor use), you could do it in a Git Hook by passing the --no-global flag when calling vale.

I'll buy that.