RFC Add mismatchedNonWorkspaceDependencies to `workspaces info` command

[lukebatchelor]

Do you want to request a feature or report a bug? Feature (it's quite small so I didn't contribute it to the yarnpkg/rfcs, but I'm happy to open it up there)

What is the current behavior? Currently yarn workspaces info returns an array with location, workspaceDependencies and mismatchedWorkspaceDependencies information. These are super useful for building on top of, but I think it would be super useful if we could also report mismatchedNonWorkspaceDependencies (non-workspace dependencies that cant be hoisted).

I'd be more than happy to give this a try if it would be accepted. The only complexities would be around trying to not duplicate too much of the logic of hoisting as it currently exists, hopefully being able to reuse that directly.

[arcanis]

I'm working in a feature that should solve this in a more generic way (basically by allowing to write cross-workspaces constraints). It'll take some time, but I hope to release it before the summer.

[lukebatchelor]

Oh sweet, would you mind giving a bit more detail on that? I'm wondering whether that is something that tries to solve all the problems for you, or whether it's something you'd build on top of to solve the problems however you want.

It might help if I explain what we're trying to do. We currently use (and built) bolt based on the original workspaces rfc, but with extra constraints.

• All external dependencies need to be declared in the root package.json
• All workspaces external dependencies need to be the exact same version as what is declared in the root
• All workspace internal dependencies must be semver satisfied by the version of the package that is in the repo

We're now looking at a slimmer, more piecemeal way of building those same constraints, but built on top of yarn workspaces except we also want to ability to explicitly opt out of the constraints (i.e pkg-a can have a different version of dependency-b for a short period of time).

We'd planned to do this by having a sort of exceptions field in the root package.json (not necessarily ins the workspaces key, but this is an example).

"workspaces" : {
  "packages": ["packages/*"],
  "exceptions" {
    "packages/foo-pkg": {
      "dependencies": {
        "dependency-b": "1.1.1"
      },
      "reason": "Team C needs this to be pinned to version 1.1.1 until BUG-1234 is fixed",
      "removeBy": "2019-02-19"
    }
  }
}

Another tool we've built and are going to be modifying for this next project is @atlaskit/build-releases. It's sort of the second half of how we kept our constraints satisfied. It takes care of automatic bumping of packages, dependencies, tagging, changelog creation, etc (similar to sematic-release, but for bolt mono-repos).

I'm only mentioning that in case it's at all relevant to what you're working on too.

I'm completely open to any discussions or contributions back to this if you are, we'd like to stay as closely aligned to yarn workspaces as possible, and contribute back as much into yarn as would be useful.

Cheers

[lukebatchelor]

Heya @arcanis , just thought I'd raise this again in case you've got time to describe how the cross-workspace-constraints might be working in the future. Any RFC's / PRs I could look at?

[arcanis]

Hey @lukebatchelor! This is what I was mentioning: https://github.com/yarnpkg/berry/blob/master/docs-legacy/workspaces-constraints.md

The tool is in an early phase (and v2-exclusive at the moment), but I'd be happy to hear your feedback (I'd suggest opening an issue on the Berry repository)! 🙂

[NickHeiner]

I came here trying to figure out what mismatchedWorkspaceDependencies is. It would be nice if yarn workspaces info responded to --help, or if these docs described the semantics of the output.

I'm happy to open a separate issue for this if you'd prefer.

[lukebatchelor]

Hi Nick,

MismatchedWorkspaceDependencies are when you have a workspace depending on another workspace, but on a version not satisfied by the one in the repo.

I.e [email protected] depends on package-b@^1.1.0 but the package-b that you have locally is at version 2.0.0.

It's important to know, because at that point package-b won't be symlinked to package-a at all. It'll get its own copy in its node_modules

[NickHeiner]

Ok, great! Ideally, that information would be in the docs. People may not find this thread when searching for mismatchedWorkspaceDependencies.

[peterboyer]

Even now in 2021: I found this thread trying to figure out what mismatchedWorkspaceDependencies means.

[JakeShirley]

Even now in 2024: I found this thread trying to figure out what mismatchedWorkspaceDependencies means.

The SEO for the docs on mismatchedWorkspaceDependencies is not great (assuming they exist?).