You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: site/src/content/docs/status/differs-to-highest-or-lowest-semver-minor.mdx
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,8 +14,8 @@ description: Same-minor dependency version differs from preferred highest or low
14
14
15
15
The instance is updated to match the preferred MAJOR.MINOR target. The range selection follows this priority:
16
16
17
-
1. If instance has a [With Range](SEMVER_GROUP_WITH_RANGE) semver group with a safe preferred range → use preferred range
18
-
2. If instance has no semver group and on-disk range is safe → preserve on-disk range
19
-
3. Otherwise → force`~` (Same Minor policy wins over unsafe ranges)
17
+
1. If instance has a [With Range](SEMVER_GROUP_WITH_RANGE) semver group with a preferred range which will not allow a version outside of the MAJOR.MINOR range to be installed, then use the preferred range
18
+
2. If instance has no semver group and on-disk range does not allow a version outside of the MAJOR.MINOR range to be installed, then preserve the on-disk range
19
+
3. Otherwise use`~` (Same Minor policy wins over unsafe ranges)
Find and remove dependencies which you've decided should never be used.
14
+
Prevent dependencies you've decided should never be used. This helps teams enforce architectural decisions—for example, preventing accidental use of legacy packages, conflicting libraries, or packages that violate your security or licensing policy.
15
+
16
+
Use this when you want to actively prevent a dependency from appearing anywhere in your monorepo, or only in specific packages. When syncpack finds a banned dependency, it flags it as an issue that must be removed.
15
17
16
18
## Configuration
17
19
@@ -49,3 +51,15 @@ This property activates this behaviour for a given Version Group.
Fix mismatched versions in this group by choosing the highest/newest semver version in use.
13
+
Require all dependencies in this group to use the highest semver version found of all the instances where it is already installed in your monorepo. When versions differ, syncpack will align them to the highest one installed.
14
14
15
15
## Configuration
16
16
@@ -33,3 +33,21 @@ Fix mismatched versions in this group by choosing the highest/newest semver vers
Have syncpack ignore the versions of these dependencies completely.
14
+
Have syncpack ignore these dependencies completely.
15
+
16
+
Defining version groups for dependencies you know you can easily fix, followed by a catch-all Ignored Version Group as the last member of your `versionGroups` array is a good way to incrementally adopt syncpack.
15
17
16
18
## Configuration
17
19
@@ -49,3 +51,11 @@ This property activates this behaviour for a given Version Group.
Fix mismatched versions in this group by choosing the lowest/oldest semver version in use.
13
+
Require all dependencies in this group to use the lowest semver version found of all the instances where it is already installed in your monorepo. When versions differ, syncpack will align them to the lowest one installed.
Relax syncpack to ensure that all versions have semver ranges which all satisfy each other, instead of having to be identical.
14
+
Checks that every instance of a dependency uses a semver range that **overlaps** with every other instance in the group. Ranges don't need to be identical — they just need to share at least one version in common (ie. they _intersect_).
15
+
16
+
This is the loosest version group policy. It does **not** enforce identical versions — the default [Highest Semver](/version-groups/highest-semver) group does that. It does **not** enforce same minor versions — use [`sameMinor`](/version-groups/same-minor) for that.
17
+
18
+
:::caution
19
+
`sameRange` only works with semver **ranges** like `^1.2.3`, `>=1.0.0`, or `~2.0.0`. Exact pinned versions like `1.0.0` and `1.0.1` are non-overlapping ranges — they will be flagged as mismatches because no single version satisfies both. If you want to enforce that exact versions share the same minor number, use [`sameMinor`](/version-groups/same-minor) instead.
20
+
:::
21
+
22
+
#### When to use this
23
+
24
+
-**Peer dependencies** where different packages legitimately need different ranges, as long as a compatible version can be resolved
25
+
-**Typed dependencies** (`foo` and `@types/foo`) that may move on different release cadences but must coexist
26
+
27
+
#### Examples
28
+
29
+
**Overlapping ranges** — at least one version satisfies both:
30
+
31
+
-`>=1.0.0` and `<=2.0.0` ✅ (versions 1.0.0–2.0.0 satisfy both)
32
+
-`>=1.0.0` and `^1.2.3` ✅ (versions 1.2.3–1.x.x satisfy both)
33
+
-`^1.0.0` and `~1.4.2` ✅ (versions 1.4.2–1.4.x satisfy both)
34
+
35
+
**Non-overlapping ranges** — no version exists in both:
36
+
37
+
-`>=1.0.0` and `<1.0.0` ✗
38
+
-`~1.0.0` and `1.4.2` ✗ (`~1.0.0` covers 1.0.x, the exact version 1.4.2 is outside it)
39
+
40
+
Mismatches in a Same Range group are **unfixable** — syncpack cannot auto-fix them because it doesn't know which range should change. You'll need to resolve these manually.
15
41
16
42
## Configuration
17
43
@@ -49,3 +75,19 @@ Choose the "sameRange" policy to apply this behaviour to a Version Group.
Pin the version of all dependencies in this group to follow the versions used by the other packages named within the `snapTo` array.
14
+
Synchronise versions by following a source package. Every dependency in this group will use the same version as defined in the packages you've designated via the `snapTo` array.
15
+
16
+
This is useful when certain packages within your monorepo are the source of truth for dependency versions. For example, if your main application package has been carefully tested with specific versions, you want all other packages to follow those same versions to ensure consistency and reduce the variables in your system.
15
17
16
18
## Configuration
17
19
@@ -50,3 +52,26 @@ Pin the version of all dependencies in this group to follow the versions used by
Copy file name to clipboardExpand all lines: skills/front-loading/SKILL.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ Then explain the trade-offs if needed.
49
49
Readers have a question in mind. Answer it in the first sentence.
50
50
51
51
**Bad (makes reader wait):**
52
-
"Syncpack is a CLI tool built in Rust. It uses a configuration file in JSON format. The configuration file specifies rules for how to synchronize dependencies. These rules can be customized per workspace..."
52
+
"Syncpack is a CLI tool built in Rust. It uses a configuration file in JSON format. The configuration file specifies rules for how to synchronise dependencies. These rules can be customized per workspace..."
53
53
54
54
Reader's question: "How do I configure Syncpack?" Buried in paragraph 3.
0 commit comments