Pattern

Text and non-HTML outputs.

Nift can track and compose any text output for which its template and dependency model is useful. The important question is not “can Nift write this extension?” but “is text templating an honest correctness model for this artifact?”

Start a text-first project

mkdir release-materials
cd release-materials
nift init --ext=.txt

The project defaults now derive content/name.txt and public/name.txt. You may rename the output directory in .nift/config.json when generated/ or dist/ communicates the project better.

A realistic multi-output project

content/
  release/summary.txt
  release/checklist.txt
  notices/third-party.txt
  feeds/releases.xml
templates/
  release-note.txt
  checklist.txt
  notice.txt
  feed.xml
  partials/legal-footer.txt
generated/
  release/summary.md
  release/checklist.txt
  notices/third-party.txt
  feeds/releases.xml
.nift/

Per-item extensions let one project own several text formats:

{
  "tracked": [
    {
      "name": "release/summary",
      "title": "Release summary",
      "template": "templates/release-note.txt",
      "content-ext": ".txt",
      "output-ext": ".md"
    },
    {
      "name": "release/checklist",
      "title": "Release checklist",
      "template": "templates/checklist.txt",
      "content-ext": ".txt",
      "output-ext": ".txt"
    },
    {
      "name": "feeds/releases",
      "title": "Release feed",
      "template": "templates/feed.xml",
      "content-ext": ".xml",
      "output-ext": ".xml"
    }
  ]
}

Usually manage ordinary entries through nift track. Edit tracked.json deliberately when an item needs per-entry extensions, then let Nift's loader validate the structure.

Compose shared text

# $[title]

Generated on $[build-date].

@content

@input('templates/partials/legal-footer.txt')

@input works the same way outside HTML: the included fragment becomes a dependency and changes invalidate only outputs that consume it. Metadata such as $[title], $[name], $[build-date] and $[build-OS] remains available.

Use template-less entries for complete source files

If the content file already represents the complete output, omit template:

{
  "name": "robots",
  "title": "Crawler policy",
  "content-ext": ".txt",
  "output-ext": ".txt"
}

Nift still parses the content as Nift source and tracks inputs/dependencies; it simply does not wrap it in another template. This is cleaner than inventing an identity template whose only content is @content.

Generated configuration needs an explicit validation step

Nift can compose JSON, XML, YAML, TOML, INI or source files as text, but it does not automatically understand every target format's semantics. If malformed output would be dangerous, validate it with the format's real parser after building:

generated:
	nift build --all
	python3 -m json.tool generated/config/app.json >/dev/null
	xmllint --noout generated/feeds/releases.xml
	./app --check-config generated/config/app.toml

Prefer a serializer when values require escaping rules, canonical typing or structural guarantees. Prefer JSON Schema or the target application's own validator when the artifact has a meaningful schema. String templates are not a substitute for those contracts.

Where text generation fits

Incremental behaviour stays useful

# Change only content/release/checklist.txt
nift status
# release/checklist is affected

# Change templates/partials/legal-footer.txt
nift status -p
# every output that includes the legal footer is affected

nift build
nift status

The value is the same as on a website: stable tracked identities, reusable fragments, explicit dependencies and explainable rebuild scope.

Release checklist

1. Run nift build --all from clean generated output.
2. Run the parser, schema checker, compiler or application validation appropriate to every generated format.
3. Inspect diffs so a template change cannot silently rewrite unrelated policy or configuration.
4. Keep authored source and generated output separate in version control and packaging.
5. Never place secrets in generated artifacts that will be committed, published or sent to a browser.