refactor(theme): work around to ensure frontmatter fields are created in the GraphQL schema

[emmenko]

Fixes #70

[vercel]

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/commercetools/commercetools-docs-kit/mt4xiq0jr
🌍 Preview: https://commercetools-docs-kit-git-nm-frontmatter-graphql-types.commercetools.now.sh

[nkuehn]

Hm, I'm a bit scared of this because it creates an actual page that we'll then have to explicitly handle in every other code that walks through pages or loops over mdx page nodes (RSS feed generators, sitemaps, release notes list etc. )

Here's the comment of one of the gatsby core maintainers concerning the topic: gatsbyjs/gatsby#5495 (comment)

He says that if you want to customize graphQL fields of other plugins, you should write a plugin that sets "fields" on the other plugin's node. Fields are intended to be added by other plugins and live in an own namespace on the graphQL node.

Another option would be to write a minimal mdx AST plugin that sets a default value on all "offical" frontmatter keys in the AST, that way the schema will always have it, too. Likely very few code but we'd have to dump or instpect the frontmatter AST to understand the data structure.

[emmenko]

Yes this is not the ideal solution and it should be taken as a (temporary?) workaround. I wouldn't consider the index.mdx to be a problem to be honest, a website usually overrides this file.

We can also name it something like __FOR_INTERNAL_USE_ONLY_DO_NOT_USE_THIS_.mdx, as long as it's picked up by GraphQL.

[nkuehn]

Not sure whether the problem is big enough to merge a workaround that's not much better than simply putting the necessary default values into each site's index.mdx now and and the site template too.

But src/content/index.mdx is definitely the best place since it will very likely be overridden.

[emmenko]

Closing in favor of #92