Update Groups
Update groups give you per-dependency control over what counts as an eligible registry update for the update command. Use them to clamp some dependencies to patch-only updates, others to minor, and to opt specific dependencies out of update consideration entirely.
How groups are assigned
When syncpack reads each instance of a dependency, it walks through your updateGroups array in source code order until it finds a match — the first match wins and syncpack stops searching.
An instance can match at most one update group. Instances which do not match any group fall through to the CLI's --target value (which defaults to latest).
When --target is set
When both the CLI's --target flag and a matched group's target apply to the same instance, the stricter of the two wins.
CLI --target | Group target | Effective |
|---|---|---|
latest | patch | patch |
latest | minor | minor |
minor | patch | patch |
patch | latest | patch |
This means you can safely set the CLI default to latest and use update groups to opt individual dependencies into stricter rules, without the CLI ever loosening a group's policy.
Examples
{ "updateGroups": [ // Storybook bumps tend to be coordinated; only ever take patch updates. { "dependencies": ["storybook", "@storybook/**"], "target": "patch" }, // Dev tooling can move freely on minor. { "dependencyTypes": ["dev"], "target": "minor" }, // Production deps stay on patch only. { "dependencyTypes": ["prod"], "target": "patch" }, // Peer dependencies are owned by consumers; never update them. { "dependencyTypes": ["peer"], "isIgnored": true }, ],}Default values
Any properties of an update group that are omitted will match-all by default, so the two examples below are equivalent.
{ "updateGroups": [ { "target": "patch" } ]}{ "updateGroups": [ { "dependencies": ["**"], "dependencyTypes": ["**"], "packages": ["**"], "specifierTypes": ["**"], "target": "patch" } ]}