fix: resolve dependency vulnerabilities via npm overrides #62
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -58,13 +58,16 @@ | |
| "zod": "^3.23.8" | ||
| }, | ||
| "overrides": { | ||
| "brace-expansion": "^5.0.6", | ||
| "fast-uri": "^3.1.2", | ||
| "glob": "^10.5.0", | ||
| "ip-address": "^10.1.1", | ||
| "minimatch": "^9.0.7", | ||
| "@hono/node-server": "^1.19.13", | ||
| "hono": "^4.12.18", | ||
| "lodash": "^4.18.0", | ||
| "postcss": "^8.5.10", | ||
| "qs": "^6.15.2", | ||
|
Comment on lines
60
to
+70
There was a problem hiding this comment. 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "Checking for publishable lockfiles..."
fd -HI '^npm-shrinkwrap\.json$' .
echo
echo "Relevant package.json fields:"
python - <<'PY'
import json
with open("package.json") as f:
pkg = json.load(f)
print("name:", pkg.get("name"))
print("version:", pkg.get("version"))
print("files:", pkg.get("files"))
print("has overrides:", "overrides" in pkg)
print("prepublishOnly:", pkg.get("scripts", {}).get("prepublishOnly"))
PYRepository: InsForge/insforge-mcp Length of output: 263 🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "Lockfile presence:"
echo -n "- npm-shrinkwrap.json: "
test -f npm-shrinkwrap.json && echo "FOUND" || echo "NOT FOUND"
echo -n "- package-lock.json: "
test -f package-lock.json && echo "FOUND" || echo "NOT FOUND"
echo
echo "NPM packaging rules:"
ls -a | rg -n '(^|/)\.npmignore$' || true
if [ -f .npmignore ]; then
echo "--- .npmignore (tail) ---"
tail -n 80 .npmignore
fi
python - <<'PY'
import json
with open("package.json") as f:
pkg=json.load(f)
print("package.json.files =", pkg.get("files"))
print("has .npmignore =", True)
PY
echo
echo "Also check if package-lock.json/shrinkwrap are explicitly ignored by files field or npmignore."
if [ -f package.json ]; then
python - <<'PY'
import json, os
pkg=json.load(open("package.json"))
files=pkg.get("files")
print("files_field_present =", bool(files))
print("package-lock.json listed_in_files =", files and "package-lock.json" in files)
print("npm-shrinkwrap.json listed_in_files =", files and "npm-shrinkwrap.json" in files)
PY
fiRepository: InsForge/insforge-mcp Length of output: 454 🌐 Web query:
💡 Result: In npm, the overrides field in package.json is explicitly designed to only be considered when defined in the root package.json file of a project [1][2][3]. Overrides specified within installed dependencies (including those in workspaces or third-party packages) are intentionally ignored by the npm CLI during dependency tree resolution [1][2][4]. This behavior is a deliberate design choice to prevent published packages from unilaterally dictating dependency resolutions for their consumers [2][4]. By restricting overrides to the root project level, npm ensures that only the end-user (the application developer) has the authority to control the dependency tree, thereby preventing potential conflicts or "ecosystem infection" that could arise if libraries were permitted to impose their own overrides [2][4]. If you are a library maintainer and need to resolve a dependency issue, the recommended approach is to ensure your package properly defines its dependencies and peer dependencies, or to publish a new version of your package that resolves the issue, rather than relying on overrides [4]. Overrides are intended specifically for application-level control, such as forcing a specific version to mitigate a known security vulnerability or to ensure consistency across the dependency graph [1][5][6]. Top results: [1][2][3][4] Citations:
🌐 Web query:
💡 Result: The file package-lock.json is not published when you run npm publish, regardless of whether you have a files field in your package.json [1][2][3]. By design, npm intentionally prevents package-lock.json from being included in the published package [1][4][5]. Even if you explicitly add package-lock.json to the files array in your package.json, or attempt to include it through other configuration, the npm CLI will exclude it [2][6]. This behavior is enforced to ensure that the lockfile does not affect the dependency resolution of consumers who install your package, as they should resolve dependencies based on the semver ranges defined in your package.json [7]. If you have a requirement where you must lock the dependency tree for consumers (such as when distributing a CLI tool or a specific production application), the npm documentation suggests using npm-shrinkwrap.json instead [1][3]. Unlike package-lock.json, npm-shrinkwrap.json is intended to be published and will be respected by the npm installer when your package is installed as a dependency [1][3]. If both files are present in the root of a project, npm-shrinkwrap.json takes precedence and package-lock.json is ignored [1][3]. Citations:
Fix:
🤖 Prompt for AI Agents |
||
| "rollup": "^4.59.0" | ||
| }, | ||
| "devDependencies": { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
P1: These
overridesentries will only take effect when thispackage.jsonis the root of an install (i.e., local dev/CI). Since this is a published package, npm ignoresoverridesfrom installed dependencies — consumers of@insforge/mcpwill still resolve the vulnerable transitive versions. To actually remediate CVEs for downstream consumers, either pin the fixed versions in directdependencies/update upstream packages, or ship annpm-shrinkwrap.jsonwhich npm does publish and honor.Prompt for AI agents