Installing Serverless v4 as a local dependency leads to ignored semantic versioning restrictions and incorrect version reporting #12886
Description
Issue description
The documentation here
implies that installing Serverless as a dev dependency of a project will allow you to "lock down" the version of Serverless:
If you already have a Serverless service, and would prefer to lock down the framework version using package.json, then you can install Serverless as follows:
# from within a service npm install serverless --save-dev
However, based on #12866 and my understanding of how auto-updating works, I suspected that auto-updates will still happen even if the user then pins a specific version of v4 (or otherwise specifies a restricted semver range) in their pacakge.json. A quick test confirmed this.
I strongly suspect the same is true of "global" installs that attempt to pin the version as well. This is a severe break from user expectation for a node module like Serverless. My projects rely on this tooling in multiple ways, in particular CI/CD speed/reliability (caching) and security (dependency scans).
Context
In a new yarn (v1) project, I added a specific v4 version of Serverless (4.4.0) as a dev dependency:
$ yarn add -D serverless@4.4.0
yarn add v1.22.22
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
success Saved 44 new dependencies.
info Direct dependencies
└─ serverless@4.4.0
info All dependencies
├─ @isaacs/cliui@8.0.2
├─ @pkgjs/parseargs@0.11.0
├─ ansi-styles@4.3.0
├─ asynckit@0.4.0
├─ axios-proxy-builder@0.1.2
├─ axios@1.7.7
├─ balanced-match@1.0.2
├─ brace-expansion@2.0.1
├─ color-convert@2.0.1
├─ color-name@1.1.4
├─ combined-stream@1.0.8
├─ cross-spawn@7.0.3
├─ delayed-stream@1.0.0
├─ eastasianwidth@0.2.0
├─ follow-redirects@1.15.9
├─ foreground-child@3.3.0
├─ form-data@4.0.1
├─ glob@10.4.5
├─ isexe@2.0.0
├─ jackspeak@3.4.3
├─ lru-cache@10.4.3
├─ mime-db@1.52.0
├─ mime-types@2.1.35
├─ minimatch@9.0.5
├─ minipass@7.1.2
├─ package-json-from-dist@1.0.1
├─ path-key@3.1.1
├─ path-scurry@1.11.1
├─ proxy-from-env@1.1.0
├─ rimraf@5.0.10
├─ sax@1.4.1
├─ serverless@4.4.0
├─ shebang-command@2.0.0
├─ shebang-regex@3.0.0
├─ signal-exit@4.1.0
├─ string-width-cjs@4.2.3
├─ string-width@5.1.2
├─ strip-ansi-cjs@6.0.1
├─ tunnel@0.0.6
├─ which@2.0.2
├─ wrap-ansi-cjs@7.0.0
├─ wrap-ansi@8.1.0
├─ xml2js@0.6.2
└─ xmlbuilder@11.0.1
Done in 3.37s.
Checked the results, confirming that the version requested in package.json (4.4.0), and the version reported by yarn why (ditto), both disagree with reality:
$ cat package.json
{
"name": "slsv4test",
"version": "1.0.0",
"main": "index.js",
"license": "NONE",
"private": true,
"devDependencies": {
"serverless": "4.4.0"
}
}
$ yarn why serverless
yarn why v1.22.22
[1/4] Why do we have the module "serverless"...?
[2/4] Initialising dependency graph...
[3/4] Finding dependency...
[4/4] Calculating file sizes...
=> Found "serverless@4.4.0"
info Has been hoisted to "serverless"
info This module exists because it's specified in "devDependencies".
info Disk size without dependencies: "5.46MB"
info Disk size with unique dependencies: "11.85MB"
info Disk size with transitive dependencies: "17.48MB"
info Number of shared dependencies: 8
Done in 0.10s.
$ yarn sls version
yarn run v1.22.22
$ /home/ejherbertson/tmp/slsv4test/node_modules/.bin/sls version
Serverless ϟ Framework
• 4.4.7
Done in 1.62s.