Front Matter is a CMS running straight in Visual Studio Code. Can be used with static site generators like Hugo, Jekyll, Hexo, NextJs, Gatsby, and many more...
I know this is far out because every SSG has a different system of adding settings, but in the end, those settings are in TOML, YAML, JSON, or INI-kind files. It would be nice to have some form of configurable option to load and edit items in the aforementioned formats and save them back.
This is a very un-thought-out idea and probably not easy to implement. But let's look for instance (selfishly) at GoHugo: We have a config directory with a _default subdirectory (or other "environment" subdirectories that are merged on top of _default when GoHugo runs). Then we have files like hugo.toml and module.toml in that _default directory. Those values are either key-value pairs or arrays and tables.
This principle could (in GoHugo) then later on even be adapted for the i18n folder that translates themes and modules.
I know this is a huge feature, so delete if it's a general "no thanks", or think about it :)
PS: there might be a general usefulness to have a TOML/YAML/JSON-to-form mechanism. Abstract without having to work on settings or translations.
PPS: Configuration option definitions could work based on a schemata file like the frontmatter schematas.
I know this is far out because every SSG has a different system of adding settings, but in the end, those settings are in TOML, YAML, JSON, or INI-kind files. It would be nice to have some form of configurable option to load and edit items in the aforementioned formats and save them back.
This is a very un-thought-out idea and probably not easy to implement. But let's look for instance (selfishly) at GoHugo: We have a
config
directory with a_default
subdirectory (or other "environment" subdirectories that are merged on top of_default
when GoHugo runs). Then we have files likehugo.toml
andmodule.toml
in that_default
directory. Those values are either key-value pairs or arrays and tables.This principle could (in GoHugo) then later on even be adapted for the
i18n
folder that translates themes and modules.I know this is a huge feature, so delete if it's a general "no thanks", or think about it :)
PS: there might be a general usefulness to have a TOML/YAML/JSON-to-form mechanism. Abstract without having to work on settings or translations.
PPS: Configuration option definitions could work based on a schemata file like the frontmatter schematas.