Skip to main content

Running a distribution

dev serves the monolith, and modular:dev runs each app on its own hostname.

pnpm dev             # the monolith, serving every app
pnpm build           # the monolith, as it is deployed
pnpm modular:dev     # every app on its own, no monolith
pnpm modular:build
pnpm docs:dev        # the documentation sites
pnpm docs:build

With a monolith

dev and build run the monolith and nothing else of the apps. The monolith already serves their routes, so running their dev servers as well would be the same routes twice, on different ports.

It compiles every app from its source, so its build waits for the libraries the apps use — built once, and cached by turbo — but not for each app's own build. turbo.json says so with a build:libs task that runs no script: a library's is its build, and a mounted app's, which add-module writes, is only its dependencies'. Turbo still hashes every app into the monolith's build, so changing one builds the monolith again.

Every app on its own

modular:dev and modular:build are the other shape. They run each app's own dev or build and not the monolith, which is what you want to work on one app in isolation, and the only shape available to a distribution too complex to serve from one deployment.

A --separate distribution has no monolith, so its dev is modular:dev.

Stable hostnames instead of ports

Several dev servers at once means several ports to remember, and a collision whenever two default to the same one. A scaffolded module's dev therefore runs through portless⁠ (external site)(portless.sh), which gives it a name:

@acme/widget:dev: > portless widget next dev
                  -> https://widget.localhost

The hostname is the package name without its scope, so @acme/widget becomes widget.localhost. Only modular:dev runs a module's dev: the monolith compiles the module itself. An app that would rather keep a port gives its dev one — next dev -p 3010 — and runs alongside the others all the same.

Documentation

Neither shape runs a documentation site. Each module's docs/ is its own workspace package, served by docs:dev and built by docs:build.