Allow specifying the desired version per dependency

[harelmo]

Description

In some cases, it's useful to align all the dependencies of a package to a pre-defined dependency, e.g. set all lodash versions across the monorepo to be ~14.17.0.

The current process is unclear in regards to how the version to set is obtained - I see it can be either the latest version of the dependency, or some other version declared by one of the packages (which I assume if picked to be such that falls within all the semver ranges defined in all the monorepo packages).

Suggested Solution

Allow providing an enforceVersions property in the syncpack file (or as a standalone syncpack-versions file, for instance), that will hold the desired versions to set for each dependency. Based on a new flag or the mere existence of the file, the dependencies across the repo would be all set to the desired versions.

For example:

...
enforceVersion: {
   production: {
     lodash: "^14.17.0",
     "fs-extra": "1.0.0"
   },
   dev: {
     lodash: "~14.0.0."
   }
}
...

The examples separates dev fro production dependencies, if for some reason they need to be set to different semver ranges, but this should probably be optional (by allowing to nest all the dependencies directly under the enforceVersion property).

This will allow both an easy alignment of dependencies in an existing repo, and also provide a clearer process of version resolution that can be reasoned about.

Help Needed

@JamieMason If you found this proposal useful, I'll be glad to be pointed to the relevant parts in the code that needs to be changed and contribute a PR.

[JamieMason]

Are Yarn resolutions or pnpm overrides a good fit for this use-case? I'm hesitant about syncpack potentially being a source of truth for version numbers, instead of package.json files.

On your other comment, there's only one method of resolution in syncpack at the moment, versions are resolved by taking the newest valid server version.

[harelmo]

Yarn resolutions / pnpm overrides are good for certain use-cases, yet they don't actually modify the package.json files across the repo but rather "magically" ignore the values declared in them, forcing other versions to be resolved instead of the explicit ones.
I actually find them more confusing than having a dedicated file added intentionally used by an external tool such as syncpack, but of course it's your call :)

Regarding:

On your other comment, there's only one method of resolution in syncpack at the moment, versions are resolved by taking the newest valid server version.

thanks for clarifying that - I think it's worth mentioning in the README, unless I've missed it.

[JamieMason]

Thinking some more, the version information would be in addition to the package.json files, not instead of, and would only change them when you run syncpack. As an opt-in this could be OK actually.

I'll mention the resolution strategy in the readme, good shout.

[harelmo]

Thinking some more, the version information would be in addition to the package.json files, not instead of, and would only change them when you run syncpack. As an opt-in this could be OK actually.

Sounds great, I'll try submit a PR soon with a suggestion

[JamieMason]

This should now be possible in 6.1.0, thanks for contributing.