`update` sets all packages to the same version in syncpack 12.3.1

[jckw]

Description

When using syncpack 12.3.1, running yarn syncpack update results in every package being given the version number of the last checked package.

e.g.

if some-package has a new version 1.2.3, and other-package has no update and the original package.json looks like:

{ 
  "dependencies": {
    "other-package": "2.3.4",
    "some-package: "1.2.1"
  }
}

then running yarn syncpack update will result in the package.json getting updated to:

{ 
  "dependencies": {
    "other-package": "1.2.3",
    "some-package: "1.2.3"
  }
}

Example screenshot here where all packages (in all package.jsons in a monorepo) are set to "0.20.17":

I originally thought this might be cache related, but nuking everything doesn't help.

Suggested Solution

Using syncpack 12.3.0 does not have this issue, suggesting the bug was introduced in the latest release.

Help Needed

[JamieMason]

Agh, thanks @jckw – that is not good! 😅

As you mentioned, I'd stay on 12.3.0 for now. Something in a1c7270 must have caused this.

update and prompt are the only commands without tests, so these kinds of mistakes happen.

[JamieMason]

I've reverted that commit in 12.3.2, I'll leave this issue open for looking at the original problem.

[yacosta738]

I have the same issue using the latest version 12.3.2

For now, the solution is to revert to the 12.3.0 version

[JamieMason]

@yacosta738 that issue with pnpm install doesn't seem to be related, please could you explain? When I npm search @lyra/utilities it is true that it does not exist:

$ npm search @lyra/utilities
NAME                      | DESCRIPTION          | AUTHOR          | DATE       | VERSION  | KEYWORDS
@lyra/preview             | Utilities for…       | =wsulibs…       | 2019-03-22 | 0.3.0    | vega vegapublish realtime content open access publishing preview
@lyra/util                | Utilities shared…    | =wsulibs…       | 2019-03-22 | 0.3.0    | vega vegapublish realtime content open access publishing util

[yacosta738]

Sorry for the delay. Yes you are right the issue was with version 9 of pnpm

It was solved by adding link-workspace-packages=true in the .npmrc

[RachelScodes]

we don't use pnpm at all and are seeing this issue on 12.3.2. and 12.3.0.

running prompt where multiple dependencies need to be updated is the issue.

prompt suggests the correct versions, I selected them:

Screenshot

but then this is what writes to my package.jsons:

Screenshot

if I go one by one, and filter prompt to one package at a time (npx syncpack prompt --filter "one-package-at-a-time"), it updates correctly.

this is my syncpack.rc

// @ts-check
const fs = require('fs');

const rootPackageJson = JSON.parse(fs.readFileSync('./package.json', 'utf-8'));

const flattenedDependencies = {
  ...(rootPackageJson.dependencies || {}),
  ...(rootPackageJson.devDependencies || {}),
  ...(rootPackageJson.resolutions || {}),
  ...(rootPackageJson.overrides || {})
};

const rootDependencies = Object.keys(flattenedDependencies)

// formatting rules (do not affect dependency version checks)
/** @type {import("syncpack").RcFile} */
const formattingRules = {
  "formatRepository": false,
  "sortAz": [
    "contributors",
    "dependencies",
    "devDependencies",
    "keywords",
    "peerDependencies",
    "overrides",
    "scripts",
    "exports"
  ],
  "sortFirst": [
    "name",
    "version",
    "private",
    "description",
    "main",
    "module",
    "types",
    "typings",
    "exports",
    "repository",
    "license",
    "author",
    "publishConfig",
    "workspaces",
    "scripts",
    "peerDependencies",
    "dependencies",
    "devDependencies"
  ],
  "lintFormatting": true,
  "lintSemverRanges": true,
};

/** @type {import("syncpack").RcFile} */
const config = {
  "source": [
    "package.json",
    "packages/*/package.json",
    "apps/*/package.json",
    "types/package.json"
  ],
  // dependency enforcement!
  // rules go from least -> most specific.
  // docs: https://jamiemason.github.io/syncpack/
  "versionGroups": [
    // legacy/conflicting dependencies can be pinned
    // {
    //   label: '@myrepo/legacy-lib is pinned to an earlier version of the sample package',
    //   packages: ["@myrepo/legacy-lib"],
    //   dependencies: ['sample'],
    //   dependencyTypes: ['prod'],
    //   pinVersion: "1.2.1",
    // },
    {
      label: '@my-monorepo/types package should not be a dependency. check the tsconfig file instead',
      packages: ["@my-monorepo/*"],
      dependencies: ['@my-monorepo/types'],
      dependencyTypes: ['!local'],
      isBanned: true,
    },
    // {
    //   doesn't work as expected
    //   label: 'Use latest version range of local packages for peer dependencies',
    //   dependencies: ['@my-monorepo/*'],
    //   dependencyTypes: ['peer'],
    //   "policy": "sameRange"
    // },
    {
      label: 'Use exact, latest version of local packages within the monorepo',
      dependencies: ['@my-monorepo/*'],
      dependencyTypes: ['!local'],
      "policy": "sameRange"
    },
    {
      label: 'All prod dependencies use exact versions the root package.json is using',
      dependencyTypes: ['!peer'],
      dependencies: rootDependencies,
      snapTo: ['my-monorepo'],
    },
    {
      label: 'All peer dependencies use version ranges that match the root package.json is using',
      dependencyTypes: ['peer'],
      dependencies: rootDependencies,
      specifierTypes: ['^'],
      snapTo: ['my-monorepo'],
    },
  ],
  // these are evaluated after the versionGroups above
  "semverGroups": [
    {
      label: 'Use ranges for peer dependencies for published libs',
      range: '^',
      dependencyTypes: ['peer'],
      packages: ["packages/*"],
    },
    {
      label: 'Use exact version for prod and dev dependencies for published libs',
      range: '',
      packages: ["packages/*"],
      dependencyTypes: ['!peer'],
    }
  ],
  ...formattingRules
}

module.exports = config;

[JamieMason]

Thanks a lot for all this detail @RachelScodes, that matches and confirms what we've been seeing. As I mentioned, the update command is new and currently quite buggy. Every other command has lots of tests and good confidence they are working, but update and prompt do not.

In the meantime I would wait before using this command. A rewrite of syncpack is coming in the next month or so and the situation should improve then.