source

If for some reason you do not want to use the same files as your package manager, you can use the source config to provide an alternative list of glob patterns to override which package.json files syncpack will operate on.

Syncpack will look in the following places for glob patterns matching package.json files, in this order of precedence, and stop looking when a match is found:

1. If --source CLI options are provided, use those.
2. If source is defined in configuration, use that.
3. If using npm workspaces or Yarn workspaces, read workspaces from ./package.json.
4. If using pnpm, read packages from ./pnpm-workspace.yaml.
5. If using Lerna, read packages from ./lerna.json.
6. Default to 'package.json' and 'packages/*/package.json'.

Adding sources without replacing discovery

By default, --source and source replace the discovered patterns. To keep workspace discovery and add extra patterns on top, set sourceMode to "extend" (or pass --source-mode extend). Discovered patterns come first; your patterns are appended last, so gitignore-style negations such as !apps/legacy can exclude discovered entries.

Polyrepos

You don't have to use syncpack with a monorepo

If your project is split over many git repositories, you could create a .syncpackrc.json with a source property targeting the package.json files in each git clone.

Then you can use syncpack to update dependencies or look for problems.

In this example we have a directory on our machine called my-projects where we git clone all of the repositories we work on for our company.

Despite us not having a monorepo, a .syncpackrc.json placed alongside each git clone allows us to use syncpack to find and fix problems.

~/my-projects/.syncpackrc.json

{
  "source": ["./*/package.json", "./*/packages/*/package.json"]
}