Core concept · 03

Project structure.

Nift is deliberately unopinionated about the rest of your repository. A useful web-project convention is to separate authored content, reusable templates, generated/public assets and Nift's small amount of project state.

A straightforward website

content/
  index.html
  about.html
  contact.html

templates/
  template.html
  partials/
    head.html
    header.html
    footer.html

public/
  assets/
    css/
    js/
    images/

.nift/
  config.json
  tracked.json

content/ contains Nift-managed page material. templates/ contains shared structure. public/ is the web-facing build/output tree in these examples and directly owns ordinary static assets. .nift/ records how Nift manages the project.

Why assets default to public/.

Most CSS, JavaScript, images and fonts are already complete browser assets. Keeping them directly in public/ gives each file one obvious source of truth and lets Nift focus its tracked graph on pages and files it actually generates. Track an asset only when it needs Nift's build-time processing.

A TypeScript/Vite frontend beside Nift

my-site/
  content/
  templates/
  frontend/
    src/
    package.json
    vite.config.ts
  public/
    assets/
  .nift/
  package.json

Vite can write bundled assets under public/assets/; Nift-generated pages can reference those concrete files with @path.

A Go-backed application

my-app/
  content/
  templates/
  public/
  backend/
    main.go
    api/
    internal/
  .nift/
  Makefile

A Node/Express application

my-app/
  content/
  templates/
  public/
  server/
    index.ts
    routes/
  .nift/
  package.json
  tsconfig.json

Nift does not require the backend, package manager or frontend tooling to live under a Nift-specific directory.

Optional page-level dependency metadata

content/
  report.html
  report.deps.json

A *.deps.json sidecar is optional. Use it when a tracked page depends on project files or directories that are not naturally discovered through template composition. See per-page dependencies →

What is actually special to Nift?

Mostly .nift/, your tracked content/template relationship, and the small amount of Nift syntax you choose to use. Everything else can follow the conventions of the tools that own it.

A Nift project can still look like your project.

The directory examples here are conventions, not a demand that every repository adopt the same architecture.

NextPartials & @input →