Configuration file

[ichiriac]

Hi @wmhilton,

It would be simpler to define a .beautify configuration file at the repository root in order to run beautify command without setting parameters.

It's something similar to other tools, the configuration would be an YAML or JSON structure and contain parameters on both extension options and processing commands (like folders and extensions).

[billiegoose]

Hmm. That's an interesting idea. When I started on this, I'd primarily thought of it as a tool for formatting newly adopted legacy codebases that were a mess, where you'd just run it once at the start of a project. In that situation having a config file doesn't make much sense. But later as I started making my custom HTML formatters, I started thinking of it as a tool that could be used in CI or as a pre-commit check. If this was something run regularly and automatically (which I think it should aspire to!) then it indeed would make sense to have a config file, similar to .babelrc or .editorconfig, or .eslintrc.json.

There is a really nice package called rc that I would lean towards using because it covers all the bases pretty much:

Given your application name (appname), rc will look in all the obvious places for configuration.

• command line arguments (parsed by minimist)
• environment variables prefixed with ${appname}_
  • or use "__" to indicate nested properties
    (e.g. appname_foo__bar__baz => foo.bar.baz)
• if you passed an option --config file then from that file
• a local .${appname}rc or the first found looking in ./ ../ ../../ ../../../ etc.
• $HOME/.${appname}rc
• $HOME/.${appname}/config
• $HOME/.config/${appname}
• $HOME/.config/${appname}/config
• /etc/${appname}rc
• /etc/${appname}/config
• the defaults object you passed in.

All configuration sources that were found will be flattened into one object,
so that sources earlier in this list override later ones.

Configuration File Formats

Configuration files (e.g. .appnamerc) may be in either json or ini format.

Do you think that would be a good fit for this project? That way users could have a default set of configuration in ~/.beautifyrc and repo level settings in /path/to/repo/.beautifyrc

[billiegoose]

Or we could use config-master which is by the same author as command-line-args and command-line-usage which I'm already using. It might actually be better because it doesn't try to interpret command line arguments or environment variables, and just walks up the current directory path rather than looking in ~ and /etc. That behavior is easier to understand and debug. And it defaults to .beautify.json rather than .beautifyrc which is a little more "with it". .rc files are kind of a throwback to UNIX... Linux users get it but the filename probably makes little sense to Windows users.

[ichiriac]

Hi @wmhilton, thanks for sharing with me rc, I like the tool, but you are right, config-master could be a greater option.

At the moment I work with various people and they don't always respect indentation. I'm not annoyed by this, for the productivity sake it's more important to write as they used but I need a way to clean up the code in order to make it more readable.

When you will finish, you/me could integrate it as a vs-code extension handler with a trigger on a shortcut, or a at save trigger (makes it more easy to use).

[billiegoose]

Alright. I'll put config-master on the TODO list!