Keep dependency versions aligned
An application has its own workspace and lockfile. Wildo carries the framework’s relevant dependency pins into that workspace and declares required peers, reducing accidental version differences between the framework and its applications.
The alignment tools update manifests. Installing dependencies makes those declarations effective; application-owned dependencies and intentionally separate toolchain choices retain their own ownership.
Example — Add a package without losing its peers
A newly composed package uses an engine library that requires peer dependencies. The delivered peer catalogue tells composition which declarations to add, while the application’s shared version overrides select their versions.
For engineers
Which authority determines the versions?
The framework root’s pnpm.overrides supplies version pins. app-dependency-alignment.mjs derives the propagated names from framework manifests, applies explicit exclusions, and reconciles application overrides. The scaffolder consumes that derived set for new standalone applications.
For a framework contributor maintaining the checked-out Wonder Todos application, these are the alignment script’s supported commands. Run them from the framework root; this is not a standalone-application CLI recipe:
node scripts/app-dependency-alignment.mjs --app examples/wonder-todos --check
# Apply manifest changes, then verify the declarations:
node scripts/app-dependency-alignment.mjs --app examples/wonder-todos --write
node scripts/app-dependency-alignment.mjs --app examples/wonder-todos --check
# Refresh the application's own installation and lockfile:
pnpm --dir examples/wonder-todos install
Review the manifest and lockfile changes together. --write does not install packages, and an override cannot supply a peer that no consumer has declared.
Why track peers separately?
engine-peer-closure.mjs computes transitive required peers. The closure is delivered as engine-peer-closure.json, so composition can add a package after scaffolding without a framework checkout. Required peers are declared with wildcard ranges; the shared override remains the version authority. Optional peers are not treated as unconditional requirements.
| Concern | Source of the answer |
|---|---|
| Which version? | The relevant framework pin, propagated into application overrides |
| Which required peers? | The engine dependency closure for the consuming package |
| What is installed? | The application’s installation and lockfile |
Reconciliation does not remove declarations merely because they no longer appear in the derived closure: an application may own them independently. Framework-development compiler, watcher and finalizer choices are deliberately outside application pin propagation.