Reducing dotfile sprawl

[lassik]

(This is quite an open-ended issue, so it could go in a number of directions, or not.)

Most sizable GitHub repos are now sprawling with an ever-increasing number of dotfiles for various build and development tools. For example, this repo has:

• .codeclimate.yml
• .gitignore
• .node-version
• .npmignore
• .travis.yml
• .unibeautifyrc.yml

And that's not even a lot by today's standards :) Consequently, it's becoming harder to browse file listings and see the substantial files (code, documentation) at a glance.

Furthermore, there are many different syntaxes for these config files: some use .ini file syntax, others JSON, still others YAML, still others are line oriented or something else entirely. Many of these files support filename patterns to apply a bunch of settings to files that match the pattern; the pattern syntax may be subtly different in different config files. Also, there are various kinds of .*ignore files that just contain file lists, but each tool has its own ignore file with subtly different syntax.

Since we are adding yet another dotfile to people's repos with this project (.unibeautifyrc*) it would be nice if we could do our part to address this problem.

I recall coming across a proposal to establish a meta directory in Git repos where one could store all these metadata/config files. Unfortunately I can't find that proposal anymore. The directory name could have been something other than meta.

I've been toying with the idea of a common attributes database (really just a YAML file or something) with its own "global namespace" where parts of the namespace would be allocated to different tools, so one could have the settings for all tools in one file. The same global namespace could also be used to arrive at a common syntax for source code comments that are parsed by tools.

Our options with Unibeautify are:

• Add another dotfile of our own.
• Put our dotfile in some kind of meta directory shared by many tools.
• Put our configs in some kind of config file shared by many tools.

Thoughts?

[lassik]

If there is interest in establishing such a a shared database, I would be quite motivated to work on it. It should use some lightweight text syntax like YAML or JSON for which a ready-made parser exists for most languages. So that projects adopting it don't need to include some fancy library. Really, agreeing upon the namespace would be the main task. Plus a common syntax for filename pattern matching (maybe just tried-and-true shell globs).

The simplest thing to get started with could be e.g. a YAML file like this:

unibeautify:
  TypeScript:
    beautifiers: ["Prettier"]
    align_assignments: false
    arrow_parens: "as-needed"
    break_chained_methods: true
editorconfig:
  "*.py":
    end_of_line: lf
    insert_final_newline: true
codeclimate:
  checks:
    argument-count:
      enabled: true
      config:
        threshold: 3

The namespace should be based on reverse DNS (like Java package names: com.example.whatever). But popular projects could apply for one-word shorthands as above.

[Glavin001]

Adding more complexity like this is something I want to avoid and also I consider it out of scope for Unibeautify. If there exists an accepted standard for configuration management -- such as what you described above -- then I'd be open to investigating and potentially adopting it. However, I do not have the bandwidth to champion a solution to this problem -- even though I agree, all of these dot files are getting out of hand 😝.

However, what I do think Unibeautify needs to support is allowing the CLI to specify configuration file path. So instead of automatically detecting the closest .unibeautifyrc file, the user can force this configuration to be located at meta/.unibeautifyrc for example. Unfortunately, this becomes a problem with Unibeautify CI which wouldn't read your scripts in package.json to see you call Unibeautify CLI with a custom configuration file path. Will need to think about this a little more.