The canonical gem source for LiquiDoc, a ruby-based documentation parsing and rendering utility enabling advanced builds with Asciidoctor, Jekyll, Liquid, and semi-structured data files.
LiquiDoc can presently write data to file using a parse action and then ingest this data in later actions. For performance reasons, the option to carry those objects in memory might offer some slight improvements. More importantly, however, we could eventually allow evaluations and other results within the config if the config could evaluate the results of parse actions.
For instance, _configs/build-docs.yml:
- action: parse
data:
- data/manifest.yml
- data/versions.yml
query: siteManifest # a GraphQL query that creates a combined object
builds:
- capture: site.manifest # store the combined object as a variable
output: _builds/data/built/manifest.yml # write the combined object as a YAML file
# no template is needed; all we are doing is morphing objects with GQL
# The following two actions are effectively identical:
- action: parse
data: _builds/data/built/manifest.yml # reads the YAML file
builds:
- output: site-manfiest.json
- action: parse
data: $site.manifest # loads the stored object
builds:
- output: site-manfiest.json
The capture: property would require the result be a proper data object or small-data format (JSON or YAML). This would work for any raw ingested data from one or more files, and including standard vars and data sub-objects, as applicable. It would also work for any data converted into a proper YAML file using Liquid. (Yes, in some cases it makes more sense to use YAML to manipulate data structures than GraphQL or any other query language, for that matter. I really need to blog this.)
LiquiDoc can presently write data to file using a parse action and then ingest this data in later actions. For performance reasons, the option to carry those objects in memory might offer some slight improvements. More importantly, however, we could eventually allow evaluations and other results within the config if the config could evaluate the results of parse actions.
For instance,
_configs/build-docs.yml:The
capture:property would require the result be a proper data object or small-data format (JSON or YAML). This would work for any raw ingested data from one or more files, and including standardvarsanddatasub-objects, as applicable. It would also work for any data converted into a proper YAML file using Liquid. (Yes, in some cases it makes more sense to use YAML to manipulate data structures than GraphQL or any other query language, for that matter. I really need to blog this.)