@fairgarden/distribution

Ship a set of versioned modules together.

End users do not care about semver. They want to know how old their copy is, and 26.09.01 says that at a glance where 1.2.1 does not. Developers do care, because semver says how much work an upgrade will be. A distribution serves both by using each where it belongs: the distribution is versioned by month, the modules inside it by semver.

@fairgarden/core  26.09.01
  @fairgarden/id          1.2.3
  @fairgarden/design      1.5.6
  @fairgarden/membership  1.0.0

Modules are git submodules, so the commit is the pin and the version is whatever the module's own package.json says. Nothing in the distribution repository restates it.

Start here

• Versioning — why two schemes, and where a version comes from
• Modules — apps, packages, and how they resolve
• Extending — one distribution built on another
• Deploying — one deployment, or many
• Running it — dev modes, and a hostname per app
• Growing a module — building in place, then extracting
• Submodule urls — what a build host can actually clone
• Commands — the fg-dist CLI
• Functions — the programmatic API

Install

pnpm add -D @fairgarden/distribution

A distribution scaffolded with init has it already, with a dist script: every command is pnpm dist <command>. Or scaffold without installing anything:

pnpx @fairgarden/distribution init distribution acme --name @acme/core

Mounting a distribution's apps into a single Next deployment is a separate concern, handled by @fairgarden/monolith.