Skip to main content

sync

Reports where each module stands.

pnpm dist sync [name...] [--no-fetch]
apps/widget      v1.0.0  -> v1.0.1 (patch), v1.1.0 (minor), v2.0.0 (major)
packages/design  v0.3.0  -> v0.3.1 (patch)
apps/legacy      untagged  no version tags

2 module(s) have newer versions. Run `pnpm dist bump` to take them, or
`pnpm dist bump --major` to include the 1 major upgrade(s).

Each line is a submodule: the version it is pinned at, the newest upgrade of each kind available, and anything else worth knowing — untagged commits past the newest tag, a pinned commit the remote does not have, uncommitted changes, a remote that could not be reached, or an ssh url.

A fork also says what it adds:

apps/id  v1.2.0+  -> v1.2.1 (patch)  fork of github.com/fairgarden/id, all in upstream v1.2.1

Its upgrades are upstream's releases, since upstream's tags are fetched too; 2 commits not upstream is work upstream does not have yet, and all in upstream v1.2.1 means unfork could go back to it.

A version shown as v1.0.0+ means the pin is a descendant of that tag rather than the tag itself.

What it also checks

The extension floor, when the distribution extends another. A module older than the parent ships is reported here as well as by check.

Submodule urls, listing any recorded over ssh with the https form to replace them with.

Pins nobody else can fetch: a module pinned at a commit that is on no branch or tag of its remote, which is what a build host would fail to clone.

Where versions come from

The tags in each module's repository, and the pin is the submodule commit. Nothing in the distribution repository is consulted — see Versioning.

Commits past the newest tag are counted and shown but never bumped to. A module with no tags at all is listed and left alone.

Options

OptionMeaning
[name...]only these modules, by name or path
--no-fetchuse the refs already present, for offline or a shallow CI clone

An unreachable remote is reported on the line rather than being fatal.