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 page-specific material. templates/ contains shared structure. public/ is the web-facing build/output tree in these examples. .nift/ records how Nift manages the project.

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 @pathto.

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.

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.