Exact same dependencies across different packages are all bundled instead of just 1?

[sneko]

Hi,

I'm using pnpm.overrides into the root package.json to fix some versions across my packages. This idea was to avoid when packageA uses packageB to have to 2 times react in the final bundle for example (if pA and pB uses react).

I used today webpack-bundle-analyzer and saw for my Next.js final build 2 MUI library listed:

• '@mui/material': 5.10.16_lskpmcsdi7ipu6qpuapyu56ihm
• '@mui/material': 5.10.16_ib3m5ricvtkl2cll7qpr2f6lvq

Whereas they are the exact same. Is overrides not sufficient? What needs to be done in addition? I thought otherwise about peerDependencies but I'm not sure if it would be the right thing and where to configure it (only in packages + listing the dependency in the root package.json?)

Thank you,

[sneko]

@zkochan I saw you are the main maintainer, any advice on this please?

(thank you for pnpm :) )

EDIT: just saw #5585 (comment) , I will read this tomorrow and give it a try :)

[zkochan]

Try with to reinstall with the new lockfile format. At least you'll have some info instead of the hashes

Set use-lockfile-v6=true.
https://pnpm.io/npmrc#use-lockfile-v6

[sneko]

@zkochan thank you it helped a lot seeing what was duplicate (I mean the dependencies that could be "merged" into one dependency whereas same versions).

For others who need this:

1. Set use-lockfile-v6=true in your .npmrc

2. Then pnpm install to get the new lockfile

3. Then analyze the top of the pnpm-lock.yaml to see which packages (yours) of your monorepo appear with different versions.

It's a bit a manual work but starts from top to bottom and look into the importers: block. It's all the direct dependencies you listed into your package.json files.

Stop at each dependency that has a version that looks with a suffix, like version: 0.31.1([email protected]) (note that something with no risk of duplication would be version: 0.31.1).

In my case for example I found for my packageA:

      '@mui/material':
        specifier: ^5.10.16
        version: 5.10.16(@emotion/[email protected])(@emotion/[email protected])(@types/[email protected])([email protected])([email protected])

Then copy into the clipboard '@mui/material': and search for all occurrences into the importer: section. If you find a different pattern of version it means it's deduplicated, for example I had for my packageB:

      '@mui/material':
        specifier: ^5.10.16
        version: 5.10.16(@types/[email protected])([email protected])([email protected])

In my case my packageA has @emotion/* dependencies that are not specified into packageB, making them a mismatch since @mui/material lists them as peerDependencies. Since I was no longer needing @emotion/* dependencies I just deleted them. Then pnpm install and there is only now version: 5.10.16(@types/[email protected])([email protected])([email protected]). Meaning it will uses the exact same package for both packageA and packageB.

In case I would have needed @emotion/* in packageA I would have been able to add them into packageB, it would make the same result of merging the dependency. The idea is just to fix the versions of peerDependencies of my different @mui/material so they can match and be merged. It's explained in https://pnpm.io/how-peers-are-resolved .

I think it can also help to make sure YOUR direct dependencies use same version everywhere in the monorepo (it's a first step before aligning peerDependencies. For this I use into my root package.json:

  "pnpm": {
    "overrides": {
      "@mui/material": "^5.10.16",
      "react": "^18.2.0",
      "react-dom": "^18.2.0",
    }
  },

(repeat the process for each dependency that you don't want to see "duplicated"...)

So first of all, thank you @zkochan , the v6 lockfile format helps a lot in catching deduplication (instead of old hash suffixes).

But I would like to say in a project with multiple developers, someone could not pay attention when adding dependencies and it would require a new manual investigation to make sure everything is aligned.

I would expect a warning message when adding a dependency (or while installing?) saying:

Hey! xyz@123 is used twice, they match the same version but have different peerDependencies so they won't be merged as one dependency. A solution would be to precise in packageX the needed missing dependencies: missing-dep-X@123

(note that is from my own experience, it's maybe not perfect, but it helped me at least ^^...)