Create rule for checking if dependencies versions are the same in different package.json

[flaviostutz]

Is your feature request related to a problem? Please describe. When the different modules of a monorepo are being developed it's normal to bump the version of a lib in the module we are working on, but forget to check or to upgrade the version in other packages. Sometimes we fix errors based on those upgrades and checks that the newer version is better, but other modules don't take advantage of this. At the same time it's not nice to force sharing all versions in a centralized package.json, as we could do with yarn, because it can break, or even make it impossible to share, different versions of the lib in one or another module. So it's a "development" effort to upgrade each module dependency version, but monolint could help at least in indicating where are the differences.

Describe the solution you'd like I would like to run monolint in the root of my repo and it would show all dependencies that are pointing to different versions among modules so me, as a developer, could take action.

Describe alternatives you've considered Using a centralized package.json of Yarn, but them I was scared of doing upgrades because I could break other modules without even knowing. I prefer to leave each module to manage its own dependencies.

@sergioflores-j @tiagostutz Pls give your two cents here.

[sergioflores-j]

I do like the idea, but I wonder if we shouldn't leave this to more elaborate tools for dependency management. E.g. npm/yarn or even NX.

Yarn has for instance yarn why. Which will list how a specific module is being resolved by all modules in a workspace.

Perhaps what we could do is a simple check for the package version specified in the package.json Although it doesn't mean much, especially if the module is installed with ^X.X.X. (in the lock file it can be resolving to a different later version)

[tiagostutz]

Yep, I agree with @sergioflores-j. Actually, how dependabot works with monorepos? Dependabot is now a "native" thing in GitHub, right?

[flaviostutz]

My idea was around just "text" checking in the different package.json files, similar to things that we do, for example, in same-contents rule. It's not meant to do anything more fancy than simply checking if the version "text" is the same or different... it shouldn't do semantic versioning checks or anything.

Actually, thinking here, if we implement #46 (move to jmespath, which is much more powerful), we will be almost there in a generic way. Nowadays we already can do the following:

With jmespath it would be possible to describe the rule for array elements, so we could check the contents of the elements that are in both files. The newer more powerful configuration (with jmespath syntax) would turn to:

{
        "package.json": {
          "selectors": [
            "scripts.dist",
            "repository.type",
            "dependencies",
            "devDependencies.{esbuild:esbuild, prettier:prettier}"
          ]
        }

}

In this example it would check if all dependencies that are in common matches the version "text", and would only check if devDependencies "esbuild" and "prettier" matches in version :)

So when the results points to an "object" type, it would check only the attributes that are in common among both found maps. By doing this we already have the capability to deal with those versions in package.jsons also (and for other things ahead).

What do you think?