Simplify front matter defaults syntax

[jaredcwhite]

Update: we ended up opting for a "data cascade" folder-based approach rather than changing the syntax of the defaults key in the config. See #139

---

I've always found the YAML syntax for defining front matter defaults to be extremely obtuse and I always have to look up a reference to remember how the heck to write it out. Really all I want to do is:

defaults:
  posts:
    layout: post
  pages:
    layout: page
  "some/path/to/stuff":
    category: stuff

Let's make this a whole lot better and then deprecate the old syntax with the goal of removing it for the 1.0 release.

Note: it should be a pretty straightforward swap because the old syntax is array-based, whereas the new one will be hash-based, so we can easily detect which syntax is being used.

[jaredcwhite]

We should do a full performance review of front matter defaults in general as part of this issue. Related issue in Jekyll: jekyll/jekyll#8188 (it's unclear to me why lazily-loading defaults improves the build time so much…not something I would expect)

[KonnorRogers]

So heres the current syntax from bridgetown-website/bridgetown.config.yaml

bridgetown/bridgetown-website/bridgetown.config.yml

Lines 17 to 34 in 8c01329

	defaults:
	- scope:
	path: ""
	values:
	image: /images/bridgetown-logo-twitter-card.jpg
	- scope:
	path: _docs
	values:
	layout: docs
	- scope:
	path: _posts
	values:
	layout: post
	category: news
	- scope:
	path: _posts/drafts
	values:
	published: false

The - scope: syntax is pretty gross I agree and I do like the idea of specifying the path as the key value.

I do like the idea of it being top level in the config rather than being nested into a _data folder.

However, I have also thought about the idea of the user defining defaults inside of a defaults.yaml file at the top level of a directory.

IE:

# ./src/_posts/defaults.yaml

layout: post
author: Jared White

Of course, I imagine the performance implications of reading multiple defaults.yaml is probably significantly worse than reading from a single source of truth.

[jaredcwhite]

@ParamagicDev I agree performance should be a concern, but since the number of defaults files would probably be fairly low for an entire site even with thousands of individual pages, I can't imagine it would be a huge hit over a single file. I really like your idea of a "data cascade" based on the filesystem itself — both Eleventy and Hugo have similar concepts, for example.

[jaredcwhite]

OK, I'm going to give the data cascade idea a try. For this initial version, I'm thinking it is only collection-scoped, so _collection_name/_defaults.yml. Next round of improvements would be to allow subfolder trees with their own unique defaults.

[jaredcwhite]

Update: I got it working with subfolder trees out of the gate. 😃 See #139

[jaredcwhite]

I'm keeping this issue open for a bit longer in case we have ideas for further improvements, but I think #139 will address most of the things people expect to do with front matter defaults.

[jaredcwhite]

I think we're good to go at this point. Closing.