# 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

```text
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