Max dependency depth
Max dependency depth is the longest dependency chain visible from the selected package. The selected package is level 0. Direct dependencies are level 1. Dependencies of direct dependencies are level 2, and the count continues until the deepest visible package.
Example: if myPackage imports dplyr, dplyr imports vctrs, and vctrs imports rlang, the max dependency depth is 3.
This value follows the current graph filters. If you lower the visible depth or hide a dependency type, the displayed depth can become smaller.
Dependency footprint
Dependency footprint is the number of unique packages reachable from the selected package through the dependency graph. A package is counted once even if multiple paths lead to it.
Example: if myPackage imports A and B, and both A and B import C, the footprint is 3: A, B, and C. C is not double-counted.
In Project mode, this is calculated from the packages you add under Project dependencies. This lets you model an R project that calls library() or require() for packages A, B, C without pretending the project is itself a CRAN package. In Package edits and New package modes, the same footprint can include Depends / Imports and LinkingTo entries.
Burden change
Burden change compares the recursive dependency footprint after your proposed Dependency Impact edits with the selected package's current recursive dependency footprint.
Burden change = dependencies after edits - dependencies before edits
A positive number means your changes introduce more recursive dependencies. A negative number means your changes remove dependencies that are no longer reached. A value of 0 means the total recursive footprint is unchanged. In Project mode and New package mode, the baseline is empty, so burden change is the full dependency footprint of the dependency set.
Shared dependency example: if you remove package A, but package B still depends on A or on packages from A's branch, those packages remain required. PkgMap keeps them visible and greys out removed direct dependencies that are still needed elsewhere.
Direct change
Direct change measures how many direct dependency entries are added or removed by your edits. Direct dependencies are packages listed directly in Depends, Imports, or LinkingTo.
Direct change = direct dependencies after edits - direct dependencies before edits
Example: if the package currently has A, B, and C as direct dependencies, then you remove B and add D and E, the direct list changes from 3 to 4. Direct change is +1.
Direct change and burden change can differ sharply. Removing one direct dependency may remove many recursive packages, or it may remove none if the same packages are still reached through another dependency.
Analysis modes
Package edits starts from the selected package and lets you model adding or removing Depends / Imports and LinkingTo entries. New package uses a synthetic package root and lets you model the Depends / Imports and LinkingTo fields for a package you are designing. Project models packages your project loads with library() or require(), so it uses Project dependencies only and hides LinkingTo.
Required R version
Required R version is the highest minimum R version declared by the selected package and the packages in its recursive dependency footprint after your edits.
Example: if your package requires R >= 4.1.0, dependency A requires R >= 3.6.0, and dependency B requires R >= 4.3.0, PkgMap reports R >= 4.3.0.
Packages without a declared R minimum do not raise the reported version. The Required R versions accordion shows which packages are attached to each R version.
Marginal dependency burden
This list shows how much of each direct dependency's recursive branch is exclusive versus shared. Exclusive packages are reached only through that direct dependency. Shared packages are also reached through at least one other direct dependency.
Example: if A imports C and D, while B imports D and E, then D is shared. C is exclusive to A, and E is exclusive to B.
Needs compilation, system requirements, and R version lists
Needs compilation lists dependency packages that declare compiled code. System requirements groups packages by external tools or libraries they declare. Required R versions groups packages by their minimum R version so you can see what is raising the overall requirement. These lists are especially useful in Project mode because they show DevOps risks down the whole dependency chain before you build a container, CI image, or deployment environment.