Circular dependency in `npm` scripts
complete
Ozymandias
💲 mkdir empty && cd empty
💲 npx @dcl/sdk-commands init
💲 npm ls @dcl/sdk-commands
dcl-project@1.0.0 ~\empty
├─┬ @dcl/asset-packs@1.20.0
│ └─┬ @dcl/sdk@7.5.2
│ └─┬ @dcl/sdk-commands@7.5.2
│ └─┬ @dcl/inspector@7.5.2
│ └─┬ @dcl/asset-packs@1.19.0
│ └─┬ @dcl/sdk@7.4.15
│ └─┬ @dcl/sdk-commands@7.4.15
│ └─┬ @dcl/inspector@7.4.15
│ └─┬ @dcl/asset-packs@1.16.0
│ └─┬ @dcl/sdk@7.4.10
│ └── @dcl/sdk-commands@7.4.10
└─┬ @dcl/sdk@7.5.6
└── @dcl/sdk-commands@7.5.6
Nicolas Earnshaw
complete
This issue has been fixed :)
Ozymandias
Fix incoming ! \o/
Ozymandias
This seems to be a good way of patching the issue, locking down the
@dcl/sdk-commands
to its latest version, preventing the runaway circular-dependency effect, while still allowing the @dcl/asset-packs
to depend on an older @dcl/sdk
: "devDependencies": {
"@dcl/js-runtime": "latest",
"@dcl/sdk": "latest",
"@dcl/sdk-commands": "latest"
[, etc]
},
"overrides": {
"@dcl/sdk-commands": "$@dcl/sdk-commands"
},
Ozymandias
Still more testing needed to be done, but for now having this in the
package.json
file, and using npx @dcl/sdk-commands
instead, works around the issue:"devDependencies": {
...
"protobufjs": "^7.2.4"
},
"overrides": {
"@dcl/sdk-commands": "npm:dry-uninstall",
}
Upon further analysis, it may be better to use the "real"
@dcl/protocol
dependency, rather than only protobufjs
.Ozymandias
The following pull-request should fix this: https://github.com/decentraland/js-sdk-toolchain/pull/977
Ozymandias
This is what it looks like after I hack the
package-lock.json
to remove this dependency.Ozymandias
Clearly the
@dcl/sdk
(or anything else) should not have a dependency on @dcl/sdk-commands
. The latter is available directly via npx
.On this graph can be seen the impact of this spurious dependency.