nanoc.yaml is currently used for configuration as well as storing site data. Splitting this up in nanoc.yaml (for configuration) and site.yaml (for site data) would help:
Be able to define a scheme for nanoc.yaml and validate it
Create site data without the fear of overwriting built-in config data
Filters and helpers could have their (default) configuration in a sub-hash, e.g.
nanoc.yaml
is currently used for configuration as well as storing site data. Splitting this up innanoc.yaml
(for configuration) andsite.yaml
(for site data) would help:nanoc.yaml
and validate itFilters and helpers could have their (default) configuration in a sub-hash, e.g.