Why is qs locked at 6.7.0?
See original GitHub issueHi,
I was going through my project dependencies and noticed I had a duplicate qs
. qs@6.9.4
is out and most of my dependencies use it. However, express
and body-parser
have a hard dependency on qs@6.7.0
. Express says it does it because body-parser does it. I looked through body-parser (code search and issues) and there doesn’t seem to be an obvious reason for it.
So my questions are:
- Why does body-parser use
qs@6.7.0
instead ofqs@^6.7.0
(caret)? - Is there anything that can be done to unlock it?
Thanks.
https://github.com/expressjs/express/issues/4171#issuecomment-582466565 https://github.com/expressjs/express/pull/4172#discussion_r375244826
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
package-lock.json · master · GitLab.org / project-templates ...
"resolved": "https://registry.npmjs.org/@babel/helper-validator-identifier/-/helper-validator-identifier-7.14.5.tgz",.
Read more >CVE-2022-24999 Detail - NVD
4 (and therefore Express 4.17.3, which has "deps: qs@6.9.7" in its release description, is not vulnerable). Severity.
Read more >Going round in vulnerability circles installing firebase-tools npm
npm install qs@latest. But I get the exact same issues. I have also. deleted my package.json-lock file and the nodule modules folder and ......
Read more >The Sikuliaq IT Asset Manager - package-lock.json at ...
"content-type": "~1.0.4",. "debug": "2.6.9",. "depd": "~1.1.2",. "http-errors": "1.7.2",. "iconv-lite": "0.4.24",. "on-finished": "~2.3.0",. "qs": "6.7.0",.
Read more >solo - part_a - package-lock.json - GitLab
"qs": "6.7.0",. 140. "range-parser": "~1.2.1",. 141. "safe-buffer": "5.1.2",. 142. "send": "0.17.1",. 143. "serve-static": "1.14.1",.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
The issue is that qs makes accidental breaking changes or otherwise undesirable changes we need to work around before bumping. We also just generally fix deps we do not own to a specific version to address the security attack when a dep is compromised and a new version published to do something malicious.
No worries on pushing a release if no one else wants it. I can easily use the
resolutions
field in mypackage.json
to bump theqs
version express/body-parser uses to dedupe it (and take responsibility for any issues I encounter by doing so).