versionGroups

Version groups split your project into isolated sections, each with their own policy for how versions should be managed.

Without any configuration, your entire monorepo is one big Highest Semver version group, but there are situations where you will want to break it up.

How groups are assigned

When syncpack reads each instance of a dependency, it walks through your versionGroups array in source code order until it finds a match – the first match wins and syncpack stops searching.

An instance can only belong to one Version Group, and the type of group it belongs to defines the rules that form its version policy.

If an instance doesn't match any of your version groups, or you don't have any, they are assigned to a default Highest Semver version group which applies to everything not already assigned to something more specific.

Order by specificity

Syncpack walks through your versionGroups array in source code order until it finds a match, the first match wins and syncpack stops searching.

Order your groups by most specific first to most general last, otherwise the generic groups will always win and the specific groups will never be read.

.syncpackrc.json

{
  "versionGroups": [
    {
      "label": "Please use lodash instead of underscore",
      "dependencies": ["underscore"],
      "isBanned": true
    },
    {
      "label": "Ignore everything else",
      "isIgnored": true
    }
  ]
}

Default values

Any properties of a version group that are omitted will match-all by default, so the two examples in the tabs below are equivalent.

Short form

{
  "versionGroups": [
    {
      "label": "Ignore everything",
      "isIgnored": true
    }
  ]
}

Long form

{
  "versionGroups": [
    {
      "label": "Ignore everything",
      "dependencies": ["**"],
      "dependencyTypes": ["**"],
      "packages": ["**"],
      "specifierTypes": ["**"],
      "isIgnored": true
    },
  ],
}