feat(versions): preserve semver group rules when fixing mismatches

[sgarfinkel]

Description

Workspace dependencies are always set to the exact version regardless of the existing semver contraints. We use "^x.x.x" for our workspace dependencies to enable npm deduping of the libraries. However, when running syncpack fix-mismatches the exact version is always used.

Suggested Solution

Use the existing semantic versioning scheme for workspace dependencies if one is already set.

Help Needed

This bug only impacts npm fortunately. On other package managers you can use pinVersion: "workspace:^" to workaround this.

[JamieMason]

Hey @sgarfinkel,
I really need to write or record some kind of tutorial or guide but haven't had the time, let's see if we can figure it out...

I can't see any of your code so this could be wrong, but one idea I have is:

1. To ensure that ^ is used where you need it to be, define a semver group which applies to where ^ should be used in your project (eg. only devDependencies and/or only specific packages or dependencies etc, whatever your rules are).
2. Try a same range group which applies only to your workspace packages, using the dependencies property.

Syncpack's default policy is for everything to have exact version numbers which are identical everywhere, but a lot of projects have their own preferences/policies, like for example:

• production dependencies should always be exact
• devDependencies should always use ^
• peerDependencies should always use >= or maybe *

So across a monorepo, any specific dependency (let's say react) could appear in more than one of the above locations – so its version cannot be identical across the entire monorepo – so that's where the need for versionGroups and semverGroups comes in, to tell syncpack what those policies are.

Hopefully this makes sense, like I said I'm flying a bit blind here, please hit me back with some more information 👍🏻

[sgarfinkel]

Hi Jamie, the issue is that I have a mix of semvers, some use ~ to ensure that dependencies remain at a particular version for compatibility reasons. Ideally, I was hoping that I could just run syncpack fix-mismatches and it would maintain the current semver while also synchronizing the dependency version appropriately.

[JamieMason]

I see what you mean now @sgarfinkel, I should hopefully have a fix for this soon.

This is the failing test I've added for what I think this scenario is, let me know if we're not both thinking of the same thing:

describe('when versions are not identical and span multiple semver groups', () => {
  const createProject = () =>
    mockIo({
      '.syncpackrc': {
        semverGroups: [
          {
            dependencies: ['**'],
            dependencyTypes: ['dev'],
            packages: ['**'],
            range: '^',
          },
        ],
      },
      'package.json': {
        name: 'a',
        dependencies: { foo: '0.3.0' },
      },
      'packages/b/package.json': {
        name: 'b',
        devDependencies: { foo: '^0.3.0' },
      },
    });

  describe('fix-mismatches', () => {
    it('considers them valid because the version number matches and the ranges are correct for each dependency type', () => {
      const project = createProject();
      Effect.runSyncExit(fixMismatches(project.io, {}));
      const filesByPath: any = project.readAllPackageJsonSync();
      expect(filesByPath['a'].dependencies.foo).toEqual('0.3.0');
      expect(filesByPath['b'].devDependencies.foo).toEqual('^0.3.0');
      expect(project.io.process.exit).not.toHaveBeenCalled();
      project.tearDown();
    });
  });
});

[JamieMason]

Released in 12.0.0-alpha.0