The number of config files per repo is slowly but surely overtaking the number of code files.

Angular
Warning: large image 1.6 MB

A brief, but not in any way exhaustive list of just the ones I’ve dealt with:

Code meta (dependencies, instructions, declarations)

* Can also be embedded into package.json

Ignore files

Docs

The Problems

Proposed Solutions

  1. Put globals in: ~/config/ (notice no preceding dot), which is the only deviance from XDG_CONFIG.

  2. Adhere to a convention and version across platforms and runtimes. Almost all of these are JSON or Markdown. config.json and README.md

Here is why I mentioned that JSON-LD is important. Search engines use JSON-LD as a standard for representing almost everything, which is documented on Schema.org. This also includes 2 specific schemas, SoftwareSourceCode, and SoftwareApplication.

Let’s pretend that magically, Node, Java, Swift, Rust, Go, Python, C, and others had their config.json(ld?) files all set and ready to go. What would happen to:

They’d all be consistent, and easily parsed, everywhere.

Side bonus: HTML already supports JSON-LD

That’s right, you can embed JSON-LD, today.

<script type="application/ld+json">
{...}
</script>

In fact, npm uses JSON-LD schemas in their registry website, which again, is very strange considering that package.json is not JSON-LD. Go to any package page like this one, and inside the HTML, you’ll find a few examples of HTML5 Microdata (a markup counterpart of JSON-LD), including the following:

<script type="application/ld+json">
    {
      "@context": "http://schema.org",
      "@type": "SoftwareApplication",
      "name": "isomorphic-fetch",
      "description": "Isomorphic WHATWG Fetch API, for Node &amp;amp; Browserify",
      "url": "https://www.npmjs.com/package/isomorphic-fetch",
      "keywords": "",
      "applicationCategory": "DeveloperApplication",
      "offers": {
         "@type": "Offer",
         "price": "0.00"
      }
    }
  </script>

Now, this also means that Web Components can leverage this same data, on top of already supporting the aforementioned HTML5 Microdata, and RDFa.

Why does it matter that HTML likes this kind of structured data? UX. Therer are multiple tools that have emerged in recent years that help people navigate dependencies and understand code at a better level.

Two such that come to mind, recalling that the “LD” stands for “Linked Data”.

Now, think of the projects that span runtimes, leveraging web languages.

There’s no way I could even speculate the possibilties.

Other potential benefits

  1. Reduce the amount of global config.

Here’s my home directory right now:

⩘ ls -H
.CFUserTextEncoding                   .oracle_jre_usage/
.DS_Store                             .ports.json
.Trash/                               .python_history
.anyconnect                           .rbenv/
.atom/                                .rnd
.babel.json                           .ssh/
.bash_history                         .subversion/
.bash_sessions/                       .travis/
.bundle/                              .v8flags.4.6.85.31.kevinSuttle.json
.cabal/                               .v8flags.5.0.71.35.kevinSuttle.json
.cache/                               .v8flags.5.0.71.52.kevinSuttle.json
.cargo/                               .v8flags.5.1.281.83.kevinSuttle.json
.cf/                                  .vim/
.cheat/                               .viminfo
.cisco/                               .vimrc
.config/                              .vscode/
.cups/                                .vscode-react-native/
.electron/                            .yarn/
.elm/                                 .yarn-cache/
.gem/                                 .zcompdump
.gitconfig                            .zprofile
.gitkraken/                           .zshrc
.gnupg/                               Applications/
.gvimrc                               Box Sync/
.histfile                             Code/
.hushlogin                            Creative Cloud Files/
.hyper.js                             Desktop/
.hyper_plugins/                       Documents/
.hyperterm_plugins/                   Downloads/
.ipfs/                                GitBook/
.iterm2/                              Hy:qp/
.iterm2_shell_integration.zsh*        IBMERS/
.jspm/                                Library/
.local/                               Movies/
.node-gyp/                            Music/
.node_repl_history                    Pictures/
.now.json                             Public/
.npm/                                 SpiderOak Hive/
.npmrc                                lib/
.nvm/                                 node_modules/
.ocamlinit                            
.opam/

And inside ~/.config/? More, based on XD_CONFIG.

⩘ ls -FH 
.DS_Store          aliases            bashrc             configstore/       fish/              prompt
PowerShell/        asciinema/         browser-launcher2/ env                git/               zsh/
README.md          bash/              colors             extras             local              zshrc

Do we really need all this? I’m not saying we should put all global config into one file, but something’s gotta give at some point.

Is this lofty and unrealistically ambitious? Maybe. Maybe not. My goal here is to document the state of things, and offer a potential solution that could work for a majority of use cases. Let’s stop reinventing the wheel and start managing our software intelligently.