RFC: First-Class Support for Workspace Consistent Versions

[gluxon]

Edit: This idea has evolved into a feature called PNPM Templates. See discussion at pnpm/rfcs#3. Also see pnpm/rfcs#1 (comment) for how the ideas between this proposal translate to the PNPM Templates proposal.

---

Motivation

A common workflow in monorepos is the need to synchronize on the same version of a dependency.

For example, the foo and bar packages of a monorepo may declare the same version of react in their package.json files.

// packages/foo/package.json
{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "^17.0.2"
  }
}

// packages/bar/package.json
{
  "name": "@monorepo/bar",
  "dependencies": {
    "react": "^17.0.2"
  }
}

Multiple versions of the same dependency can cause different flavors of problems.

• In projects that bundle dependencies, multiple versions inflate the size of the final result deployed to users.
• Differing versions result in multiple copies that may not interact well at runtime, especially if features like Symbol() are used. For example, React hooks will error if a component is rendered with a different copy of React in the same app.
• For TypeScript, multiple copies of the same @types package causes compile errors from mismatching definitions. The compiler diagnostic for this is usually: "argument of type Foo is not assignable to parameter of type Foo". For developers that have seen this before, they may realize this diagnostic is due to a dependency version mismatch. For developers newer to TypeScript, "Foo is not assignable to Foo" is very confusing.

While there are situations making differing versions become unavoidable, this is usually accidental. Multiple differing versions arise from not reviewing pnpm-lock.yaml file changes or not searching for existing dependency specifiers before adding a new one. The later is typically unwritten convention in most monorepos.

Summary

Instead of every workspace package declaring a version range on a dependency, a new workspace-consistent version specifier protocol would allow packages to delegate to a range defined at the root package.json.

Minimal Example

A sample root `package.json` configuration would appear as such:

// package.json
{
  "name": "example-monorepo",
  "private": true,
  "pnpm": {
    "workspaceConsistent": {
      "versions": {
        "jest": "^27.5.1",
        "react": "^17.0.2",
        "react-dom": "^17.0.2"
      }
    }
  }
}

Workspace packages can then refer to the configured root defined version ranges:

// packages/foo/package.json
{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "workspace-consistent",
  }
}

// packages/bar/package.json
{
  "name": "@monorepo/bar",
  "dependencies": {
    "react": "workspace-consistent",
    "react-dom": "workspace-consistent"
  },
  "devDependencies": {
    "jest": "workspace-consistent"
  }
}

The resulting `pnpm-lock.yaml` file would persist as:

lockfileVersion: X.X # TBD

workspaceConsistent:
  # Spaces after each block are intentional to help git auto merge version changes.
  jest:
    specifier: ^27.5.1
    dependency: 27.5.1

  react:
    specifier: ^17.0.2
    dependency: 17.0.2

  react-dom:
    specifier: ^17.0.2
    dependency: 17.0.2

importers:

  .:
    specifiers: {}

  packages/foo:
    specifiers:
      react: workspace-consistent
    dependencies:
      react: workspace-consistent

  packages/foo:
    specifiers:
      jest: workspace-consistent
      react: workspace-consistent
      react-dom: workspace-consistent
    dependencies:
      jest: workspace-consistent
      react: workspace-consistent
      react-dom: workspace-consistent_react@workspace-consistent

# No proposed changes to the packages section.
packages:

  /jest/27.5.1:
    # Omitted for brevity

  /react/17.0.2:
    # Omitted for brevity

  /react-dom/[email protected]:
    # Omitted for brevity

  # Additional transitive dependencies omitted for brevity
  

Peers Suffix Elaboration

It's worth elaborating on the lockfile resolved version for react-dom, which was recorded as: workspace-consistent_react@workspace-consistent for the minimal example above.

The react@workspace-consistent portion (after the underscore) is referred to as the "peers suffix" in pnpm nomenclature. A "peers suffix" appears in this case since react-dom declares a peer dependency on react.

Without workspace consistent versions, this would normally render as [email protected]. The 17.0.2 portions are intentionally replaced with workspace-consistent to keep changes to the lockfile small. The extra indirection allows edits to be limited to the workspaceConsistent and packages section whenever the workspace changes its react or react-dom version. See Merge conflicts in pnpm-lock.yaml are reduced for the problem this solves.

Rationale for First-Class Support

While there's existing tooling in the frontend ecosystem for consistent versions (syncpack being one great option), builtin support from pnpm allows several improvements not otherwise possible.

1. Merge conflicts in pnpm-lock.yaml are reduced

When upgrading a dependency intended to be consistent across workspace packages, any blocks under the importers key containing that dependency will have line changes in pnpm-lock.yaml.

Suppose a commit upgrades react and react-dom to ^18.0.0-rc.3 in the minimal example without workspace-consistent usage. This results in git merge conflicts if another commit:

• Changes the version of a dependency line-adjacent to the upgraded dependency.

  Suppose the current HEAD commit upgrades jest. On git merge, the following conflict manifests.

  # pnpm-lock.yaml
  packages:
  
    packages/bar:
      specifiers:
  <<<<<<< HEAD
        jest: ^28.0.0-alpha.7
        react: ^17.0.2
        react-dom: ^17.0.2
  =======
        jest: ^27.5.1
        react: ^18.0.0-rc.3
        react-dom: ^18.0.0-rc.3
  >>>>>>> upgrade-react

• Add or removes a dependency line-adjacent to the upgraded dependency.

  Suppose the current HEAD commit deletes jest from bar. On git merge, the following conflict manifests.

  # pnpm-lock.yaml
  packages:
  
    packages/bar:
      specifiers:
  <<<<<<< HEAD
        react: ^17.0.2
        react-dom: ^17.0.2
      dependencies:
        react: 17.0.2
        react-dom: [email protected]
  =======
        jest: ^27.5.1
        react: ^18.0.0-rc.3
        react-dom: ^18.0.0-rc.3
      dependencies:
        react: 18.0.0-rc.3-next-de516ca5a-20220321
        react-dom: 18.0.0-rc.3-next-de516ca5a-20220321_1d81fe1bff57e86f30d2d405110ea7f4
      devDependencies:
        jest: 27.5.1
  >>>>>>> upgrade-react

  A similar merge conflict arises if redux was added since it would be declared below react.

  # pnpm-lock.yaml
  packages:
  
    packages/foo:
      specifiers:
  <<<<<<< HEAD
        react: ^17.0.2
        redux: ^4.1.2
      dependencies:
        react: 17.0.2
        redux: 4.1.2
  =======
        react: ^18.0.0-rc.3
      dependencies:
        react: 18.0.0-rc.3-next-de516ca5a-20220321
  >>>>>>> upgrade-react

• Adds a new declaration of the upgraded dependency.

  Suppose the current HEAD commit adds a react-dom declaration to foo:

  # pnpm-lock.yaml
  packages:
  
    packages/foo:
      specifiers:
  <<<<<<< HEAD
        react: ^17.0.2
        react-dom: ^17.0.2
      dependencies:
        react: 17.0.2
        react-dom: [email protected]
  =======
        react: ^18.0.0-rc.3
      dependencies:
        react: 18.0.0-rc.3-next-de516ca5a-20220321
  >>>>>>> upgrade-react

As monorepos grow in workspace package count, merge conflicts become increasingly more probable. On GitHub, any merge conflict in pnpm-lock.yaml blocks pull requests due to lack of custom merge driver support.

With first-class support for workspace consistent versions, edits on upgrades are limited to the root package.json and the workspaceConsistent portion of pnpm-lock.yaml. This reduces churn in pnpm-lock.yaml, and prevents merge conflicts in all the cases listed above.

Previous discussion: #4324 (comment)

2. Consistent versions can be declared directly in package.json files.

Existing tooling rely on a synchronization step that edits all package.json files on a dependency upgrade. For example, developers may find + replace "react": "^17.0.1" to "react": "^17.0.2" across a repository.

• These edits lead to churn in package.json files and merge conflicts with other commits editing package.json files.
• Repository maintainers have to remember to run this synchronization step periodically, or create a Continuous Integration step to verify the repo is in a good state.

3. Intention becomes clear

There might be a tight relationship between foo and bar.

{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "^17.0.2"
  }
}

{
  "name": "@monorepo/bar",
  "dependencies": {
    "react": "^17.0.2"
  }
}

A developer working primarily in @monorepo/bar may not realize the implied coupling and upgrade @monorepo/bar to react@18 without realizing an edit to @monorepo/foo was also required.

The workspace-consistent protocol makes it more clear from just reading package.json when a dependency is intended to be consistent across the monorepo. Ideally this person would search "workspace-consistent package.json` online and find pnpm.io docs.

Implementation

The primary implementation changes happen in pnpm-lock.yaml read and write.

On read, any workspace-consistent references will be replaced with the aliased version when deserializing the lockfile into memory. On write, the in-memory versions would be replaced with workspace-consistent.

This process may not be possible if the lockfile in a broken state.

• If the workspace-consistent is specified for a dependency in the lockfile not present in the root package.json, installation will abort.
• If the workspace-consistent resolution is specified for a dependency not present in the workspaceConsistent lockfile block, a best case resolution will be made following existing semver range to concrete version logic.

Other Changes

Similar to the workspace: protocol, pnpm publish will need to dynamically replace instances of workspace-consistent with the value specified in the root package.json.

There may be changes to pnpm update to make sure it respects workspaceConistent versions, but the existing version deduplication logic may do that already.

Elaboration

Semver Range Specifier in Workspaces

Readers familiar with the workspace: protocol may be curious as to why the workspace-consistent: protocol does not allow a semver range specifier for publishing like the workspace: protocol does. This is because the behavior on publish may be confusing.

Walking through an example of the confusing behavior:

// package.json
{
  "pnpm": {
    "workspaceConsistent": {
      "versions": {
        "react": "^17.0.0",
      }
    }
  }
}

Assume the react specifier ^17.0.0 resolved to 17.0.2.

# pnpm-lock.yaml
workspaceConsistent:
  react:
    specifier: ^17.0.0
    dependency: 17.0.2

Suppose semver ranges were indeed allowed on workspace-consistent:. If a package were to specify workspace-consistent:^:

// packages/foo/package.json
{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "workspace-consistent:^",
  },
}

On publish this is expected to become:

{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "^17.0.0",
  },
}

It would be surprising if this became ^17.0.2 (created by adding ^ to the resolved version) since that may be overly specific and leave authors with no way to relax that.

On the other hand, suppose a package were to specify workspace-consistent:*:

// packages/foo/package.json
{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "workspace-consistent:*",
  },
}

On publish, the least suprising behavior would be for this to become 17.0.2. This is because 17.0.2 was the resolved version actually tested on in the monorepo.

{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "17.0.2",
  },
}

This leads to a discrepancy between what workspace-consistent:* and workspace-consistent:^ should append semver range types to on publish. (The original specifier vs the resolved version.)

The semantics may become more clear if workspaceConsistent configured versions must be a concrete version, but this eliminates the ability to pnpm update workspaceConsistent values.

Lockfile workspaceConsistent block format

The proposed format is:

workspaceConsistent:
  jest:
    specifier: ^27.5.1
    dependency: 27.5.1

  react:
    specifier: ^17.0.2
    dependency: 17.0.2

  react-dom:
    specifier: ^17.0.2
    dependency: 17.0.2

An alternative format that represents the same information would be:

workspaceConsistent:
  specifiers:
    jest: ^27.5.1
    react: ^17.0.2
    react-dom: ^17.0.2
  dependencies:
    jest: 27.5.1
    react: 17.0.2
    react-dom: 17.0.2

The alternative format better matches the existing shape of importers. However the proposed format is more resilient to merge conflicts. Separate commits changing the version of react and jest would merge conflict with the alternative format, while the proposed format would merge those changes cleanly.

Extensions

Transitive Consistency

Multiple versions of a package can still end up in the final product due to versions declared as a dependency of a dependency.

It would be useful to declare two extra fields to solve the duplicate dependency problem completely.

{
  "name": "example-monorepo",
  "private": true,
  "pnpm": {
    "workspaceConsistent": {
      "groups": {
        "default": {
          "@types/react": "^17.0.43",
          "react": "^17.0.2",
          "react-dom": "^17.0.2",
        }
      },
      "enforceConsistencyTransitively": true,
      "allowTransitiveMismatches": ["@types/react"]
    }
  }
}

enforceConsistencyTransitively will error if there is ever more than one item in the packages block of pnpm-lock.yaml for a dependency, even duplicates on the same version but appearing multiple times due to peer dependencies.

The allowTransitiveMismatches option will provide an escape hatch in case specific dependencies are acceptable. In the case above, duplicate @types/react dependencies may be acceptable since it's usually under devDependencies and package authors may declare a semver range without any overlap on the monorepo workspace consistent range.

Allowed Deviations

The default behavior is to show an error if a workspace package does not use workspace-consistent for a configured dependency. However, sometimes a workspace package may not be able to use the same version of a dependency as the other packages in the monorepo. The allowedDeviations option can be used as an escape hatch.

Once specified, @monorepo/baz will be allowed to declare a version range that does not begin with workspace-consistent for @types/react.

{
  "name": "some-monorepo",
  "pnpm": {
    "workspaceConsistent": {
      "groups": {
        "default": {
          "@types/react": "^17.0.43",
          "react": "^17.0.2",
          "react-dom": "^17.0.2",
        }
      },
      "allowedDeviations": {
        "@types/react": ["@monorepo/baz"]
      },
    }
  }
}

Version Groups

Users may want to declare different subset partitions of consistent version sharing. Borrowing the phrase version groups from syncpack, this could be defined as such:

{
  "name": "example-monorepo",
  "private": true,
  "pnpm": {
    "workspaceConsistent": {
      "groups": {
        "default": {
          "react": "^17.0.2",
          "react-dom": "^17.0.2",
          "redux": "^4.1.2"
        },
        "react-rc": {
          "react": "^18.0.0-rc.3",
          "react-dom": "18.0.0-rc.3"
        },
        "react-next": {
          "react": "18.0.0-rc.3-next-033fe52b4-20220325",
          "react-dom": "18.0.0-rc.3-next-033fe52b4-20220325"
        },
      }
    }
  }
}

Workspace packages would then use workspace-consistent:<version-group> as the protocol. Simply workspace-consistent would refer to the default group.

An edge case arises if a package overlaps its version group usage.

{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "workspace-consistent:react-rc",
    "react-dom": "workspace-consistent:react-next"
  }
}

These scenarios are likely mistakes. While installation can continue without problems, an error should be emitted to be helpful. To produce the error a check algorithm would record usages of a non-default version group and the dependencies declared inside of it. If another version group is selected for a dependency present in a previously declared group, installation will fail.

Note that the algorithm above would permit this alternative scenario, which is likely not a problem.

{
  "name": "@monorepo/foo",
  "dependencies": {
    "react": "workspace-consistent:react-rc",
    "react-dom": "workspace-consistent:react-rc",
    "redux": "workspace-consistent"
  }
}

Alternatives

Comparison to overrides/resolutions

An alternative mechanism for declaring workspace consistent versions is the pnpm.overrides feature. While mechanically this allows you to set the version of a dependency across all workspace packages, it can be a bit unexpected when if pnpm.overrides rewrites a dependency's dependency to an incompatible version silently.

pnpm.overrides is ultimately intended for a different purpose. The NPM RFC for a similar feature explicitly states that it should be used as a short-term hack to fix vendor problems.

Using this feature should be considered a hack in most cases, something that is done temporarily while waiting for a bug to be fixed, or to avoid excessive duplication caused by an overly strict meta-dependency specifier.

https://github.com/npm/rfcs/blob/main/accepted/0036-overrides.md

The workspace-consistent protocol is conversely intended for long-lived usage.

[gluxon]

Version groups complicate this a lot, especially with the non-overlap check. The initial implementation would likely be a lot easier without version groups, but I suspect it'll be one of the first features asked for if this gets usage. What are the thoughts around whether it's worth the further implementation complexity?

Adding some background to the transitive consistency check listed in the Extensions section: I think this is worth getting in. I proposed the base idea of workspace-consistent to a more senior frontend developer on a different team at work. They mentioned that this doesn't solve the problem fully, and they do frequently catch duplicate versions in pnpm-lock.yaml in pull request reviews. I do the same when I'm reviewing code, but admittedly don't catch these as thoroughly as my aforementioned coworker does before the PR merges.

---

Other than that, I'm really excited for this feature if approved. I think this will become the preferred way to declare dependencies on my team.

[NickDarvey]

Version groups would be the ideal feature for us. We use PNPM with Rush so we already have a way to ensure consistent versions across the monorepo. However, in our monorepo we have distinct areas (which align with areas of our business) with several packages within each area. There's limited, carefully defined dependencies between areas. Some areas are stable and only occasionally upgrade packages, others are quicker moving and want to keep up-to-date. Version groups would mean each area can move at their own pace.

[dmichon-msft]

Version groups are something I've already been looking to implement in Rush, since I need them for internal usage, e.g. when having some legacy projects on an old version of React, and the existing common-versions functionality is somewhat brittle for consistency enforcement. Only the versions in allPreferredVersions get enforced right now (in the sense that any dependency specifier in the entire tree that can be satisfied by the preferred version will be). Version ranges are neat for external consumers to control their own dependency layout, but for internal usage I need to lock everything down as tightly as possible from a security and compliance standpoint.

[gluxon]

@NickDarvey I wasn't aware that Rush had this feature; appreciate the link. Thanks for confirming version groups are valuable.

@dmichon-msft. Big fan of rush. Thanks for working on it.

[zkochan]

The Bit CLI already supports version groups.

For instance, I can tell Bit to use react@16 and react-dom@16 in any component that is under the components/legacy folder

workspace.jsonc:

{
  "teambit.workspace/variants": {
    "components/legacy": {
      "teambit.dependencies/dependency-resolver": {
        "policy": {
          "dependencies": {
            "react": "16",
            "react-dom": "16"
          }
        }
      }
    }
  }
}

I recommend you to learn about Bit. It uses pnpm (or Yarn) under the hood and removes a lot of boilerplate in your monorepo. You don't even have to maintain individual package.json files for your components. Bit automatically detects what packages your component imports and generates a package.json.

[gluxon]

@zkochan I'll hold off on drafting a PR together until I get your thoughts. Just in case this is something we no longer want to do given #4475.

Otherwise I'd be happy to work on this and own any maintenance after the feature merges.

[zkochan]

I can't give you an answer about it now. It is really big.

Please copy the text from the issue to a new RFC file here and make a PR: https://github.com/pnpm/rfcs/tree/main/text

It will be easier to discuss it in a PR.

[gluxon]

Thanks for creating the pnpm/rfcs repo, that was a good idea. Opened here: pnpm/rfcs#1

I can't give you an answer about it now. It is really big.

Understood. Please take your time reviewing. (That goes for any other pnpm maintainers helping too.) I'd rather not rush this either.

[chengcyber]

I believe version management in a monorepo is essential, and consistent version feature in pnpm is great.

I would like to write down a more lightweight proposal here:

Assuming

- root
  |- packages
    |- a
    |- b

if a, b both depends on react

package.json for A

  "dependenices": {
     "react": "17.0.1"
  }

package.json for B

  "dependencies": {
    "react": "16.8.0"
  }

1. Configure for consistent version

I prefer pnpm-workspace.yaml

packages:
  - packages/*
consistentVersions:
  - react

semantically, this configuration means the version of package react should be consistent in workspace.

1.1 '*' should be supported, it means every package version should be consistent.
1.2 '!' should be supported, for example, !foo means the version of package foo can be inconsistent

consistentVersions:
  - '*'
  - !foo

2. When to check consistency?

2.1 Maybe a new CLI command pnpm check-consistent-version

When pnpm check-consistent-version runs, throw version inconsistent error.

2.2 pnpm install/ pnpm add

When pnpm install/add runs, throw version inconsistent error. The logic of pnpm check-consistent-version should be reused.

3. What is consistency?

• package A declares "react": "17.0.1", package B "must" declare "react": "17.0.1".
• meanwhile, package B declares "react": "16.8.0", package A declares "react": "16.8.0 also meet the requirement of consistent version

In a nutshell, consistent validates the version number in each package.json

4. How to control inconsistency?

Like i said, version management is essential to a workspace. In fact, a different package version is actually intentionally. We should encourage users to use "*" in consistentVersions as much as possible.

In this situation, another configuration is used to allow alternative versions.

pnpm-workspace.yaml

packages:
  - packages/*
consistentVersions:
  - '*' 
allowedAlternativeVersions:
  react:
    - 16.8.0  # <--- this is a list

In this way, user can declare [email protected] is allowed in workspace.

[gluxon]

Hey @chengcyber, appreciate you giving this a look. I think we're roughly on the same page.

A few things I like about this lighter weight solution:

1. By default you can specify that every dependency must be consistent.

2. Placing the config in pnpm-workspace.yaml makes this read a lot cleaner.

   I'm unsure what configs belong in package.json vs pnpm-workspace.yaml. Looking over the docs, pnpm-workspace.yaml has very minimal usage while package.json has lots of existing usage. I'm relatively non-opinionated here though.

I am biased towards the full solution using a new workspace-consistent protocol however:

1. Without the new version specifier protocol, monorepos won't see any of the 3 benefits under Rationale for First-Class Support.
2. There isn't a need to run a synchronization command (e.g pnpm check-consistent-version).

[chengcyber]

Hi @gluxon

By default you can specify that every dependency must be consistent.

This is very very important. Like if someone create a new package in workspace. The version management should be involved automatically. Use the example of consistent react version to "17.0.1", new package use "react@16" should throw error. If the new package do want to use "react@16", extract work should be taken (same idea as shameful-hosit), and it should be explicitly write somewhere for code review("allowAlternativeVersions" in my proposal).

Placing the config in pnpm-workspace.yaml makes this read a lot cleaner.

Two reasons:

1. The consistent version mainly for workspace
2. You can leave comments in yaml, while comments in package.json is not officially supported.

There isn't a need to run a synchronization command (e.g pnpm check-consistent-version).

I have no objections if new pnpm command is not needed.

Without the new version specifier protocol, monorepos won't see any of the 3 benefits under Rationale for First-Class Support.

I can see the advantages of the new version specifier protocol. but i think it should be a advance usage, rather than basic usage. I prefer a lightweight basic usage. It helps 1. easy to adapt; 2. cover for most cases.

Imaging the new version specifier protocol is mandatory to make consistent version work, it's too hard for user to manage every packages. Ideally, it's always good to lower the cost for good thing, meanwhile make a higher cost for bad thing.

[gluxon]

but i think it should be a advance usage, rather than basic usage.

Ah I see. I like the idea of making this easier to use incrementally. I agree at the moment this proposal as written would be a bit frictionful to start using. Users would have to replace existing versions with the new protocol.

I have 2 unpolished ideas here. I'll elaborate on them in the new pull request pnpm/rfcs#1 and mention your username for thoughts. Edit: Going to just continue the discussion here for now.

[gluxon]

Idea 1:

I suspect a pnpm workspace-consistent migrate command would go a long way towards making this easier to convert in existing repos. For example, pnpm workspace-consistent migrate @types/node would replace existing version ranges with workspace-consistent:* and update the workspaceConsistent config (whichever file that lives in) accordingly. It would also setup allowedDeviations/allowedAlternativeVersions if necessary and warn on the packages that are declaring an inconsistent version range.

I'd imagine a pnpm workspace-consistent migrate --all command that would behave similarly. One approach there would be to specify a <threshold> where dependencies with some percentage of existing reused version specifiers get migrated to the new protocol. Example: If 95% of your packages declared react with ^17.0.2, that's probably supposed to be a consistent version and the remaining 5% should be added to allowedDeviations until that's fixed later.

Idea 2:

Would it help if there's a flag telling pnpm add to automatically record consistent versions for new dependencies to the workspace at package.json/pnpm-workspace.yaml/consistent-versions.json?

Imaging the new version specifier protocol is mandatory to make consistent version work, it's too hard for user to manage every packages.

I suspect the ideas above make the friction to manage every dependency in this manner comparable?

• If you don't use the workspace-consistent: protocol, you'd have to open another package.json and copy the version range there, and then run pnpm install.
• If you do use the workspace-consistent: protocol, you just pnpm add <pkg> and you're done.

With those ideas, are there other workflows that make workspace-consistent: more frictionful than duplicating version ranges in multiple package.json files? Genuinely asking.

I like the idea of making this easier to use incrementally.

Thinking about this a bit more, I worry about the workspace-consistent: protocol getting mixed usage with duplicated (but same) version ranges. That fees like it might get confusing? I'm not sure if incremental usage is needed if you have a migration command.

[weyert]

Sounds quite similar to the existing node cli tool called syncpack?

[gluxon]

Yup, it's indeed very similar. The RFC mentions syncpack a few times. The version groups feature is a direct inspiration from syncpack.

[weyert]

Oh I missed that. Personally, I am happy to use syncpack for this task. Don't have strong feelings to have be part of pnpm

[gluxon]

I think that's totally fair. I'd like to do something first-class (i.e builtin to pnpm) since upgrading consistent dependencies causes massive PRs in our team's monorepo at the moment, which result in merge conflicts. Fixing that requires a change to make pnpm understand these consistently versioned dependencies.

Most repos likely don't hit this scale, but I think large monorepos with ~100 commits a day run into it regularly. I suspect most teams just fix the merge conflicts and move on, but I see a way to avoid them (almost) entirely with this proposal.

[lake2]

It's a nice featrue. I can't wait to use it.

[gluxon]

Thank you! I'm excited too. 🙂

[i7eo]

Nice feature, I am looking forward!

[jakeleventhal]

is there any traction or plans to implement this or is this just in RFC stages

[zkochan]

This is the new RFC: pnpm/rfcs#3

[gluxon]

Thanks to everyone for following along. I'm going to close this discussion in favor of a new proposal at pnpm/rfcs#3 for now. The ideas translate fairly closely and accomplish the same goal. See pnpm/rfcs#1 (comment) for details of how the ideas map.