[Feat] Dependency Version Strategy Validation

[wvanrensselaer]

Problem Statement

We have a growing monorepo and are opting for a versioning strategy of pinning all workspace dependencies to exact versions. This makes it clear exactly what version of a dependency a package is using and also during upgrades what the new version is without needing to consult the lockfile or use package manager commands (yarn why). We would like to enforce this versioning strategy in CI and it seems like it might be a good fit/complement to the one version verification.

One note is that it is generally better to opt for ranges with libraries but we are not publishing libraries from this monorepo and are using the one version rule to keep versions consistent between apps and libraries.

Proposed Solution

I think the version strategy could be configured in the one-version.config.json config file. Also open to suggestions on format here:

{
  "versionStrategy": "exact" // or "range", etc
}

In the case you need to opt out of the version strategy in extenuating circumstances, we can allow overrides:

{
  "versionStrategy": {
    "type": "exact",
    "overrides": ["react"] // Allow React to be a range
  }
}

While we could allow per-package overrides I think this conflicts with the goal of the one version rule in general (keeping versioning consistent across all packages in the monorepo).

The version strategy would then be validated during the one version check (one-version check). For the exact version strategy we would error on the baz dependency in the following package:

{
  "name": "foo",
  "dependencies": {
    "bar": "1.2.3",
    "baz": "^1"
  }
}

Alternatives Considered

We've presently implemented this validation as a standalone script run as a separate step in CI, but thought it might make a good addition here.

Additional Context

No response

[michaelwclark]

One version is pretty cool, I might give it a go in my mono-repo, but what Iv'e found has worked well for me is using yarn resolutions and no-hoist.

I'll set resolution for a package name in my root package.json, and if i need a particular version of a package for a child package in the repo then I'll add nohoist for that package.

If you'd like one-version for this repo I wouldn't mind giving it a shot for my next hacktober item.

[github-actions[bot]]

Automatically marking issue as stale due to lack of activity

[hamlim]

I don't think this issue should be considered stale, but also could understand if we wanted this to not be something that the one-version package cares about.

[github-actions[bot]]

Automatically marking issue as stale due to lack of activity

[github-actions[bot]]

Automatically closing this issue as stale