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

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