Skip to main content

Module dependent_version_graph

Module dependent_version_graph 

Source
Expand description

The dependency walk and the plan of dependent bumps. What: Walk the workspace dependency graph from the packages whose version was raised and plan a patch bump for every publishable package that reaches one of them. Why: A dependent’s published contents change when a dependency it ships with changes, so its version must move too. This is the incumbent’s closure and filter (dependent-version-bump.ts:183-350): edges to names outside the workspace and self edges are ignored, the walk passes through unpublished packages and cycles, and only publishable, versioned, not-yet-raised packages are bumped.

In TS you’d write (pseudocode):

// planDependentBumps({ manifests, bumpedNames, publishableNames });

Structs§

PlannedBump
What: One planned dependent bump. Why: The plan turns each into a manifest text edit and a finding.
WorkspaceNode
What: One workspace package as the walk sees it. Option<Vec<u16>> is the version as JavaScript code units, or nothing. Why: Edges are the names this package reaches through runtime fields or bundled development imports; which ones count is decided before the walk.

Functions§

plan_dependent_bumps
What: The patch bumps for publishable dependents of the raised packages, sorted by name. Result<T, UnsupportedVersion> is the plan, or the first dependent (in node order) whose version cannot be bumped automatically. Why: Raised packages already moved; a package without a version has nothing to bump; an unpublished package is never released, though the walk passes through it.
transitive_dependent_names
What: Every package that transitively depends on one of bumped_names. &[String] borrows a list of names; the result owns its names. Why: The walk keeps a work stack of names whose dependents still need visiting, so it ends on cycles and never recurses. A raised package reached from another raised package is in the result; the caller decides what that means.
utf16_order
What: Order names as JavaScript’s < does, by UTF-16 code units. std::cmp::Ordering is less, equal or greater. Why: Rust compares Strings by UTF-8 bytes, which orders characters above U+FFFF differently from characters between U+E000 and U+FFFF.