Enhancement: Allow frontmatter.json to be split in multiple files

When describing complex content types, frontmatter.json quickly become a long and unreadable file. I just finished creating a content type describing Hugo various front-matter fields, and my frontmatter.json has 211 lines of content, and this is just with one complex content type and some frontmatter settings.

Hugo allows to split is configuration file in multiple files stored in config folder, and named according to the config section they store. An example of Hugo splitted config can be found at https://github.com/razonyang/hugo-theme-bootstrap-skeleton/tree/main/config/_default

Frontmatter could allow a similar setup in .frontmatter/config to allow an atomic configuration.

Another option is to allow the use of an import directive in frontmatter.json where the user explicitly import another file in lieu of a parameter value.

[estruyf]

Pushed the current change for the new beta. The feature is not yet complete, but already available to give it a try to see if we’re on the right path.

Current settings which can be split into folders/files are:

• Content-types: .frontmatter/config/taxonomy/contentTypes
• Page folders: .frontmatter/config/taxonomy/pageFolders
• Placeholders: .frontmatter/config/taxonomy/placeholders
• Snippets: .frontmatter/config/taxonomy/snippets

I’ve also created a sample project: https://github.com/FrontMatter/project-samples/tree/main/docusaurus

Let me know what you think.

[michaeltlombardi]

My only suggestion to the proposal outlined is that the convention always replace . with folder level, so instead of (not reordered for alphabetic sorting, sorry):

.
├── .frontmatter/
│   └── config/
│       ├── taxonomy.contentTypes/
│       │   └── *.json
│       ├── taxonomy.contentTypes.json
│       ├── content.placeholders/
│       │   └── *.json
│       ├── content.placeholders.json
│       ├── content.snippets/
│       │   └── *.json
│       └── content.snippets.json
└── .frontmatter.json

It would be:

.
├── .frontmatter/
│   └── config/
│       └── taxonomy/
│       │   ├── contentTypes/
│       │   │   └── *.json
│       │   ├── contentTypes.json
│       └── content/
│           ├── placeholders/
│           │   └── *.json
│           ├── placeholders.json
│           ├── snippets/
│           │   └── *.json
│           └── snippets.json
└── .frontmatter.json

I think those three sections - taxonomy.contentTypes, content.snippets, and content.placeholders make enormous sense for a first pass. I think in the future it would absolutely be useful to be able to do data.*, taxonomy.fieldGroups, and taxonomy.customTaxonomy.

For me, the ideal end state is to be able to have most or all fields definable via this split definition, with non-arrays defined in their nearest ancestor .json. For example:

// .frontmatter/config/taxonomy.json
{
  "frontMatter.taxonomy.seoContentLength": 1760,
  "frontMatter.taxonomy.seoDescriptionField": "description",
  // etc for the non-arrays
}
// .frontmatter/config/taxonomy/contentTypes/foo.json
{
  "name": "foo",
  "pageBundle": false,
  "fields": [
    {
      "title": "Title",
      "name": "title",
      "type": "string",
      "single": true
    },
    // snipped for brevity
  ]
}
// .frontmatter/config/taxonomy/contentTypes/bar.json
{
  "name": "bar",
  "pageBundle": false,
  "fields": [
    {
      "title": "Title",
      "name": "title",
      "type": "string",
      "single": true
    },
    // snipped for brevity
  ]
}

With the deterministic file/folder name, we could know what schema to apply where.

On possible future DevX

In the example above, I used the full key names in the split config. To be very clear, I believe that’s how this should be implemented initially because I expect it’s the least amount of work. However, I think a possible enhanced UX would be this instead:

// .frontmatter/config/taxonomy.json
{
  "seoContentLength": 1760,
  "seoDescriptionField": "description",
  // etc for the non-arrays
}

But that would require some schema rework (or copying the schema partially and maintaining it separately, which seems rough - def more thought needs to go into the maintainability of something like this). I just wanted to note it here because if I didn’t do it now, I would entirely forget.

I really, really like this proposal. I also think sorting this out is something of a prerequisite for #407, especially since this model would make maintaining “packaged” configurations easier and will already require some work on merging. This is also much more relevant to the majority of the user base.

My own config file is 767 lines long without the hundreds of lines I would need for my data type definitions.