Lerna v10 pins most of its dependencies
Current Behavior
Check the current package.json:
{
"dependencies": {
"@npmcli/arborist": "9.1.6",
"@npmcli/package-json": "7.0.2",
"@npmcli/run-script": "10.0.3",
"@nx/devkit": ">=23.1.0 < 24.0.0",
"@octokit/plugin-enterprise-rest": "6.0.1",
"@octokit/rest": "20.1.2",
"ci-info": "4.3.1",
"cmd-shim": "6.0.3",
"columnify": "1.6.0",
"conventional-changelog": "8.1.0",
"conventional-changelog-angular": "9.2.1",
"conventional-commits-filter": "6.0.1",
"conventional-commits-parser": "7.1.2",
"conventional-recommended-bump": "12.1.0",
"cosmiconfig": "9.0.0",
"dedent": "1.5.3",
"envinfo": "7.13.0",
"execa": "5.0.0",
"fs-extra": "^11.2.0",
"git-url-parse": "14.0.0",
"handlebars": "4.7.9",
"import-local": "3.1.0",
"ini": "^1.3.8",
"init-package-json": "8.2.2",
"inquirer": "12.9.6",
"js-yaml": "4.3.2",
"libnpmaccess": "10.0.3",
"libnpmpublish": "11.1.2",
"load-json-file": "6.2.0",
"make-fetch-happen": "15.0.2",
"minimatch": "3.1.4",
"npm-package-arg": "13.0.1",
"npm-packlist": "10.0.3",
"npm-registry-fetch": "19.1.0",
"nx": ">=23.1.0 < 24.0.0",
"p-map": "4.0.0",
"p-queue": "6.6.2",
"pacote": "21.5.1",
"read-cmd-shim": "4.0.0",
"semver": "7.7.2",
"signal-exit": "3.0.7",
"ssri": "12.0.0",
"string-width": "^4.2.3",
"tar": "7.5.22",
"tinyglobby": "0.2.12",
"validate-npm-package-license": "3.0.4",
"validate-npm-package-name": "6.0.2",
"write-file-atomic": "5.0.1",
"yargs": "17.7.2"
},
}Most dependencies are pinned to an exact version, while most of these packages are very likely respecting semver.
Pinning these dependencies to exact versions is problematic for npm audit and similar security scanners.
Currently, in our Docusaurus monorepo, most reported vulnerabilities come from Lerna because of these pinned dependencies. Upgrading to the latest version of Lerna doesn't fix anything, obviously, and the only workaround would be to use package manager overrides.
Even if these audits usually report many false-positive issues on code that may never run, it's still annoying to pin dependencies this way and prevent users from cleaning up their npm audit.
Someday there might be a true positive in a dependency you pin. If there is one true positive issue in Lerna v9, it's easier to upgrade a transitive dependency through its semver range than to upgrade Lerna to v10+, and backporting security fixes to older versions is not fun.
I'm not sure if this has been discussed before, but it's unclear to me why all these versions are pinned. I'd suggest taking the opposite approach, assuming these packages are respecting semver unless proven otherwise, and using ^ for all deps by default.
Expected Behavior
Using semver ^ ranges instead of pinned versions
Related
Source: lerna/lerna