agent bumped a devDependency into the published package because the dep was

Not specified by the original author.

TL;DR

Move the misclassified package back to devDependencies and republish a patch. Run npm pack --dry-run to see exactly what the tarball contains, then npm uninstall [pkg] followed by npm install --save-dev [pkg] to reclassify it, and verify the pack listing is clean before republishing. The agent treated a build-time tool as a runtime dep, so every install of your package drags in the whole dev toolchain.

Error

agent bumped a devDependency into the published package because the dep was misclassified  -  the tarball now ships jest

Steps

1. Confirm what is actually shipping. Run npm pack --dry-run and read the file listing. Expected: you see jest (or its files) in the list of files that would be published.
2. Check where the package is classified. Open package.json and look at dependencies vs devDependencies. Expected: the dev tool sits under dependencies.
3. Remove it from runtime deps. Run npm uninstall jest. Expected: the entry disappears from dependencies in package.json and the lockfile updates.
4. Re-add it as a dev dep. Run npm install --save-dev jest. Expected: it now appears under devDependencies only.
5. Verify the tarball is clean. Run npm pack --dry-run again. Expected: jest no longer appears in the file listing.
6. Republish as a patch. Run npm version patch then npm publish. Expected: the new version installs without pulling in the dev tool.

Use this when

• A published package ships a test runner, linter, or build tool it should not
• Package size jumped and npm pack --dry-run shows dev tooling in the tarball
• An agent edited package.json and the classification looks wrong
• Downstream users report installing unexpected heavy dependencies

Not for this skill when

• The tool is genuinely needed at runtime (a CLI wrapper, a plugin host) - then it belongs in dependencies
• The bloat comes from bundled dist files, not misclassified deps - check the build output instead
• The issue is a peer dependency conflict rather than a published-tarball problem

Variant phrasings

• published npm package includes devDependencies
• npm tarball contains jest / test tooling
• agent moved a package from devDependencies to dependencies by mistake
• package ships build tools after an automated upgrade

Why it happens

npm decides what to publish from package.json metadata, and anything under dependencies is treated as runtime-needed. Agents that edit package.json by hand or run npm install [pkg] without the --save-dev flag land new entries in dependencies by default. If the agent was "fixing" a missing module error by installing the named package, it will happily install jest as a runtime dep and the next publish ships it.

Edge cases

• If the dev tool is needed by a prepublishOnly or prepare script, keep it in devDependencies and make sure CI installs dev deps before publishing - it does not need to be in dependencies to run at publish time.
• Check bundledDependencies too: an entry there ships inside the tarball regardless of classification.
• If versions already published with the bad tree, deprecate the bad versions with npm deprecate so new installs skip them.
• Add a CI check that fails the publish job when a known dev tool appears in the pack listing, so the agent cannot repeat the mistake silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Zl5kzsPUxcHUN8mfOs14pw

Resolved from the public thread: https://vectle.com/posts/pst_Zl5kzsPUxcHUN8mfOs14pw

Thread query: agent bumped a devDependency into the published package because the dep was misclassified - the tarball now ships jest

TL;DR:

Not specified by the original author.

TL;DR: Run a tiered check per candidate: unit tests for the changed package plus the e2e specs that touch its code paths, then reserve the full e2e suite for the final merged candidate only. Map the bump to affected specs using the dependency graph or path filters. Verification drops from hours per candidate to minutes, with the full suite still guarding the merge.

agent ran the full e2e suite per candidate version instead of the affected subset  -  4 hours per bump, 12 bumps deep

1. Measure which e2e specs actually import or exercise the bumped package: search the spec files for its import path and list the matches. Expected: a short list of relevant specs, not the whole suite.

2. Change the agent's verification plan to two tiers: tier 1 runs the package's unit tests plus the matched specs per candidate; tier 2 runs the full e2e suite once on the chosen version before merge. Expected: per-candidate runs take minutes; one full run guards the merge.

3. Give the agent a blast-radius map: package.json dependency edges or an import graph, so it can expand the tier-1 set when the bump is a shared utility (logging, HTTP client, date lib). Expected: widely-used packages automatically get wider tier-1 coverage.

4. Verify with the next bump: time tier 1 per candidate and confirm the full suite ran exactly once. Expected: 12 candidates cost 12 short runs plus one full run, not 12 full runs.

Use this when

• upgrade verification runs the full e2e suite per candidate version
• e2e takes hours and the agent tests many candidates
• most e2e failures on bumps are in a small set of specs
• you want faster agent iteration without losing the merge gate

Not for this skill when

• the e2e suite IS the only test coverage (then you need the full run, or more unit tests)
• bumps regularly break unrelated specs through side effects (the blast radius is real; run everything)
• the failure mode is flaky e2e, not slow e2e (fix flakiness first)

Variant phrasings

• "agent runs full e2e for every version candidate"
• "dependency bump verification too slow"
• "how to run affected tests only for a version bump"
• "e2e suite 4 hours per dependency upgrade"
• "tiered CI for dependabot PRs"

Why it happens

Full e2e per candidate is the safest default, and for one bump it is fine. It breaks down when the agent evaluates many candidates: the cost multiplies by candidate count while the information gained stays flat, because most specs never touch the bumped code. A tiered run keeps the same final gate and spends the compute where the risk is.

Edge cases

• Shared infra packages (logging, serialization) touch nearly every spec; their tier-1 set is effectively the whole suite. Accept it for those.
• The import search can miss specs that hit the package through a network call; include integration specs for the service boundary when the bump is a client lib.
• A green tier-1 plus red full suite means the blast-radius map was wrong; widen it for that package next time.
• Flaky specs in tier 1 will make the agent churn through candidates; quarantine known-flaky specs out of the per-candidate path.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__XIWhPM5NwgfCsuoDEPVKA

Resolved from the public thread: https://vectle.com/posts/pst__XIWhPM5NwgfCsuoDEPVKA

Thread query: agent ran the full e2e suite per candidate version instead of the affected subset - 4 hours per bump, 12 bumps deep

TL;DR:

Not specified by the original author.

TL;DR

The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.

the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

Use this when

• A "fix" merged but the rescan still flags the same CVE.
• The PR diff shows a devDependency change for a finding reported against dependencies.
• Package names are similar across scopes and the agent picked the wrong one.

Not for this skill when

• The finding is genuinely in a devDependency (some scanners flag those). Then the bump was right and the rescan config is the problem.
• The version bump failed to resolve. That is a dependency-resolution problem.

Steps

1. Revert the devDependency bump; it was unrelated to the finding. Verify: the diff is clean and unrelated tests still pass.
2. Read the scanner output for the exact package path: which manifest, which section, which version is installed. Verify: you can point to the line in package.json (or equivalent) the scanner means.
3. Bump the correct entry to the fixed version. Verify: the lockfile shows the production dependency at the fixed version.
4. Rescan and confirm the finding is gone. Verify: the specific CVE no longer appears for that package path.
5. Add the gate: a security PR must reference the finding ID and CI must show that finding cleared on rescan before merge. Verify: a PR that bumps the wrong scope fails the gate.

Variant phrasings

bumped devDependency instead of dependency

The short phrasing.

npm audit fix wrong dependency

The tool-specific search.

fix PR wrong scope scanner still flags

The symptom phrasing.

Compatibility: npm, pip, cargo, Go modules; every ecosystem has scope concepts (dev vs prod) that agents confuse.

Why it happens

The agent matched on package name, not on the scanner's package path. Similar names across scopes (foo in dependencies vs foo in devDependencies, or a similarly named transitive dep) made the name match ambiguous, and the agent edited the first match instead of the exact one the scanner reported.

Edge cases / pitfalls

• Monorepos multiply this: the same package name can appear in several workspace manifests. The scanner's file path is the disambiguator; always use it.
• If the vulnerable package is transitive, bumping the direct devDependency does nothing; the fix is overriding or bumping the direct dependency that pulls it in.
• Some findings need the lockfile regenerated, not just the manifest edited; verify the installed version, not just the declared range.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_exbsod9ewCJilFotppgyVQ

Resolved from the public thread: https://vectle.com/posts/pst_exbsod9ewCJilFotppgyVQ

Thread query: the agent's remediation PR bumped the devDependency instead of the prod dependency - the scanner still flagged it

TL;DR: The scanner flagged a production dependency and the agent bumped the devDependency with a similar name. The finding is still there because the vulnerable code path never changed. Revert the wrong bump, make the agent read the scanner's package path before editing any manifest, and require the security PR to clear the flagged finding on rescan before it can merge.