fix: avoid multiple version conflict in node_modules

[bluelovers]

http://npm.github.io/how-npm-works-docs/npm3/how-npm3-works.html

[achingbrain]

Could you please add some context around the problem you are trying to solve?

[bluelovers]

u can just need type yarn list --pattern *ipfs*

when u use in other project, will see multiple version of same package

this node_modules problem, and should try avoid bound version in dependencies by change package.json

├─ [email protected] <=========
├─ [email protected]
├─ [email protected] <=========
│  └─ [email protected] <=========
├─ [email protected]
├─ [email protected]
├─ [email protected]
│  └─ [email protected] <=========
├─ [email protected]
│  └─ [email protected]
├─ [email protected]
│  └─ [email protected] <=========
├─ [email protected]
│  ├─ [email protected] <=========
│  └─ [email protected] <=========
├─ [email protected]
│  ├─ [email protected] <=========
│  └─ [email protected] <=========

[achingbrain]

I create a new project and ran yarn add ipfs then listed the deps:

$ yarn list --pattern *ipfs*
yarn list v1.22.4
warning package.json: No license field
warning No license field
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
│  └─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
├─ [email protected]
│  └─ [email protected]
└─ [email protected]
✨  Done in 0.59s.

I don't see duplicate modules the same way you do (aside from ipfs-http-client which will be fixed by libp2p/js-libp2p-delegated-content-routing#30 and libp2p/js-libp2p-delegated-peer-routing#23).

Do you have other dependencies in your package.json that are causing this?

[bluelovers]

u can't always ask developer update package dep
when they didn't change any code in project
with that project just is a sub util lib

that's why should avoid it from package.json

[achingbrain]

Is the problem here that you are loading the wrong version of a module? Or is it that your node_modules folder is large?

[bluelovers]

that will be hidden issue, because u can't know one of package is load wrong version

when ur new version not a semver patch

also if u try force update deps

"resolutions": {
    "ipfs-unixfs-importer": ">= 0.44.1"
  },

u can see just update one ipfs-unixfs-importer will be avoid many package is duplicate

but u can't do force it, when user install ur package ( yarn / npm both can't fully force it when it is sub of sub package , deep... )
so better way is change package.json pls

if u don't like use peerDependencies, then pls use >= when ur version number always not a patch

[bluelovers]

for now it is small, if not try avoid it, one day u will see some thing like this

[bluelovers]

also if can, try use something keep deps is new before u publish new version
but don't use git bot, because it will spam git branchs

for me, im use yarn-tool ncu -u for update deps, after u can use yarn-tool install update install

  "name": "ws-ipfs",
  "version": "1.0.0",
  "private": true,
  "workspaces": [
    "packages/@lazy-ipfs/*",
    "packages/*"
  ],
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "prepublish:lockfile": "npx sync-lockfile .",
    "lerna:publish": "npx lerna publish",
    "lerna:publish:yes": "npx lerna publish --yes --cd-version patch",
    "ncu": "npx yarn-tool ncu -u && npx yarn-tool ws exec yarn-tool ncu -- -u",
    "sort-package-json": "npx yarn-tool sort"
  },

[achingbrain]

I really don't think this is a good idea.

A module declares a dependency on a version of another module because it is coded to the API of that version of the module.

If you then configure your project to override transitive dependency versions, there's no guarantee that loaded modules will have the expected API (known as JAR or DLL hell in other languages), leading to runtime bugs that are frequent, subtle and hard to diagnose.

[bluelovers]

when ur api is same, ur result is same, i don't think any reason, it should have multiple version exists

also peerDeps not mean override version, it just make u i think deps in parent project, because u have more deep cycle, u will more easy get same pkg has multiple version

even if it just xxx.xxx.1, xxx.xxx.2