The number of config files per repo is slowly but surely overtaking the number of code files.
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
- CODE OF CONDUCT
- Far too many package managers.
- No one seems to notice that JSON has an alarming number of flavors, official and unofficial. · JSON5: main draw is comment support
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,
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: - GitHub search? - App Store searches? - Package registry searches? - Google, Disconnect, DuckDuckGo, Bing, etc searches? - BigQuery results?
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.
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:
"description": "Isomorphic WHATWG Fetch API, for Node &amp; Browserify",
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”. - http://octolinker.github.io/ - https://sourcegraph.com/
Now, think of the projects that span runtimes, leveraging web languages. - http://electron.atom.io/ - https://facebook.github.io/react-native/ - http://ionicframework.com/ - tons more
There’s no way I could even speculate the possibilties.
Other potential benefits
- Reduce the amount of global config.
Here’s my home directory right now:
⩘ ls -H
.gvimrc Box Sync/
.hushlogin Creative Cloud Files/
.npm/ SpiderOak Hive/
And inside ~/.config/? More, based on
⩘ 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.