add support for json or yaml config file

[briancappello]

I added this because frontmatter is specified in yaml, and to me having the config in yaml feels more consistent. If found config.toml still takes precedence, so I don't think there would be any BC breaks. What do you think?

[KyleAMathews]

I'm kinda inclined to say no on this. It would be nice it's true to be able to add site wide data in any number of data formats... which is exactly what you'll be able to do in 1.0. But this feels a bit like needless complication. Maybe. Is there anyone for who figuring out toml was a serious roadblock for using Gatsby? But on the other hand this is a very clean PR and it wouldn't be hard to support this so even if it's a marginal gain it'd still be worth it on a cost/benefit analysis.

Thoughts?

[briancappello]

Using Gatsby was the first time I'd heard of toml, but you're right, it's not like it's hard to figure out. I'm not very attached to this specific change - is there an issue I could take a look at with your thoughts for the 1.0 site wide data?

A little off-topic, but the biggest roadblock I've had has been lack of documentation - specifically, with regards to injected props like route(s), getting the current page in the template, finding top-level pages or parent page data, that kind of stuff (on the plus side, it's forcing me to read the code :) ) I think at this point I've about figured it all out.

Anyways, no worries if you just wanna kill this PR. If you change your mind and wanna merge it, let me know and I'll squash the commits

[KyleAMathews]

@briancappello here's my initial writeup (and subsequent discussion) on the new GraphQL-based data layer #420. I gave a talk as well recently on it at the GraphQL Summit — https://www.youtube.com/watch?v=y588qNiCZZo / https://graphql-gatsby-slides.netlify.com

Yeah — let's kill this then. The general rule in product work is unless a feature is a clear win then kill it because kinda good features combine to eventually cause featuritis. A dread disease :-)

On documentation — agree. I was kinda hoping Gatsby would avoid getting popular until 1.0 came out and I'd just document that but clearly that didn't happen :-) Do you think I could divert some of your PR energies that direction? While what you found is confusing is still fresh-in-mind, I'd appreciate a PR documenting these even if it's just an FAQ-style outline. Perhaps add a docs directory for these as our README is getting unwieldy now.

[aendra-rininsland]

I totally disagree with the points made earlier in this issue (apologies if the following sounds at all whingey) — personally, I would love to be able to use a non-TOML format for config.

Reasons:

• Like @briancappello, I had never heard of TOML before Gatsby. Having to learn a new syntax just to configure a single project is ultra painful.
• The documentation on gatsbyjs.org is mostly in JS. As is, I'm failing to figure out how to translate the plugins directive into TOML (further exacerbated given the one REPL I've found online seems to not work properly with array values).
• It adds an extra dependency
• The audience for Gatsby will undoubtedly be most familiar with JSON
• (Sundry personal reasons why I feel TOML itself is a far inferior format to JSON or YAML, which I'll spare you. 😉)
• AFAICT, things like backticks path: "${__dirname}/pages/" won't work in TOML.

Another idea — instead of having a dedicated config file (which, for my current Gatsby project is like 4 lines before "plugins"), why not just put a new stanza in package.json for Gatsby config? This also has the added benefit of being where I do most of my config these days (TypeScript, Babel and Eslint all enable configuration via package.json).

Just a thought, considering if you wanted to redo how config is done, 1.x would be a good time to do it.