add-module
Adds a module repository as a submodule and wires it into the distribution.
pnpm dist add-module <url> [--at <dir>] [--name <mount>] [--ssh]
pnpm dist add-module https://github.com/acme/widget.git
Added apps/widget from https://github.com/acme/widget.git
Shipping @acme/widget@1.2.0, as the checkout declares it
Linked through the workspace in apps/monolith/package.json
Mounted at /widget in apps/monolith/next.config.ts
turbo.json: the monolith's build waits for its libraries, not its own build
Run pnpm install and `fg-monolith merge-package-json`.
What it does
Clones the submodule, then reads the checkout to decide the rest.
Placement. A repository with routes is an app and stays at apps/<name>;
one without is a package and is moved to packages/<name>. --at overrides.
Linking. The module is depended on with workspace:* — never a version,
since the submodule is the pin.
Mounting. An app is added to the monolith's Next config. A package is not: it is depended on, not served. Neither happens if the distribution has no monolith.
The config is parsed to find the mount map and the entry is spliced into the original text, so formatting and comments survive. When it cannot be edited — the apps declared somewhere else, say — you get the line to paste rather than a failed command that has already added the submodule.
Building. The monolith compiles a mounted app from its source, so an app
gets a build:libs task in turbo.json that waits only for its dependencies:
the monolith's build then builds the app's libraries but never the app on its
own. See running a distribution. Only in a
distribution whose turbo.json has build:libs.
Options
| Option | Meaning |
|---|---|
--at <dir> | where to put it, overriding the app/package decision |
--name <mount> | mount name, which becomes the URL segment |
--ssh | record the url as given rather than rewriting it |
The module is noted in the distribution's changelog.