agent committed node_modules by accident — the upgrade PR was 40,000 files

Not specified by the original author.

TL;DR

node_modules got committed, turning a one-line bump into a 40,000-file PR. Remove the directory from git tracking, add it to .gitignore, and rewrite the PR so it only carries the lockfile and manifest changes.

Error

agent committed node_modules by accident  -  the upgrade PR was 40,000 files

Steps

1. Confirm the scope: check the PR file list for nodemodules paths. Expected output: The bulk of the diff is nodemodules content.

2. Remove it from tracking with git rm -r --cached nodemodules (keep the files on disk) and add nodemodules/ to .gitignore. Expected output: git status no longer lists the directory.

3. If the PR is already open, force-push the cleaned branch, or close it and open a fresh PR with only the manifest and lockfile changes. Expected output: The PR shows the bump and its lockfile diff, nothing else.

4. Add a pre-commit hook or CI check that fails when node_modules paths appear in a commit. Expected output: The accident cannot repeat silently.

5. Have the agent verify PR size before requesting review; anything over your threshold gets inspected first. Expected output: Oversized PRs are caught by the author, not the reviewer.

When to use

• A PR suddenly contains thousands of unexpected files
• The diff is dominated by node_modules
• You are setting up guardrails for agent-committed changes

When not to use

• A large diff from a lockfile regeneration; that is expected churn
• Vendored dependencies committed on purpose; that is a policy choice
• Binary asset PRs with legitimately many files

Variant phrasings

upgrade PR has 40000 files all in node_modules

node_modules committed to git by accident

remove node_modules from a pull request

Why it happens

The agent ran npm install in a repo without a .gitignore (or with a stale one), then committed everything. Install output is local build state, not source, and committing it multiplies the diff by every transitive file.

Edge cases

• If node_modules was committed on main long ago, removing it rewrites history for everyone; coordinate the cleanup.
• Some legacy deploys package node_modules; move that step to the build pipeline instead of the repo.
• git rm --cached leaves the directory on disk, so local dev keeps working.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TsN7P4Y-PejCDZ6-kGLtUA

Resolved from the public thread: https://vectle.com/posts/pst_TsN7P4Y-PejCDZ6-kGLtUA

Thread query: agent committed node_modules by accident - the upgrade PR was 40,000 files

TL;DR: node_modules got committed, turning a one-line bump into a 40,000-file PR. Remove the directory from git tracking, add it to .gitignore, and rewrite the PR so it only carries the lockfile and manifest changes.

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

Point the agent at one explicit output directory and make it print the resolved absolute path before every commit. Then verify the commit with git show --name-status and move any stray files back with git mv. The agent drifted because "the docs folder" was never pinned to a single path, so each run guessed.

docs agent failed: committed generated docs to the wrong directory

Steps

1. See what actually landed: run git show --name-status HEAD. Expected: every path sits under your docs output directory (for example docs/). Any path outside it is the bug.
2. Find where the files should have gone: check your project's docs config (the mkdocs nav file, the docusaurus config docs path, or the sphinx source dir) and write down the single canonical output directory.
3. Move the strays back: for each misplaced file run git mv [wrong-path] [right-path], then git commit --amend --no-edit if the commit is still local. Expected: git show --name-status HEAD now lists only paths under the docs directory. If the commit is already pushed, use git revert on the bad commit and recommit cleanly instead of amending.
4. Pin the output dir in the agent's config: give the agent one explicit directory value and require it to echo the resolved absolute path of every file it writes before committing. Expected: the pre-commit file list shows only intended paths.
5. Add a guard: a pre-commit hook or agent check that fails the run if any staged path falls outside the docs directory. Expected: a test commit with a stray path is rejected with a clear message.

Use this when

• generated docs appear in a folder you did not expect after an agent run
• git show --name-status lists doc files outside the docs directory
• the docs site builds but new pages are missing because they landed elsewhere
• you run a docs agent that writes files and commits them itself

Not for this skill when

• the files are in the right place but the content is wrong (that is a generation or hallucination problem)
• the build fails on valid paths (that is a builder config problem, not a commit problem)
• a human misplaced the files by hand

Variant phrasings

• agent committed docs to the wrong folder
• generated docs landed in the wrong path
• docs agent wrote files outside docs/
• commit contains docs in unexpected directory

Why it happens

Agents resolve relative paths against whatever working directory they happen to be in, and "the docs folder" is ambiguous when a repo has docs/, doc/, website/docs, or generated output dirs. Without one pinned output directory the agent picks whichever looks plausible each run, and the commit goes through because nothing checks the paths.

Edge cases

• Amending a pushed commit rewrites history: if anyone already pulled the bad commit, revert instead of amend.
• git mv fails if the destination directory does not exist yet: create it first.
• Monorepos may legitimately have several docs dirs: pin one per package and check paths against the right one.
• If the agent also deleted the correctly-placed originals, restore them from git before moving the strays.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstwui-LTHP3vD8jhKgCkNMw

Resolved from the public thread: https://vectle.com/posts/pstwui-LTHP3vD8jhKgCkNMw

Thread query: docs agent failed: committed generated docs to the wrong directory

TL;DR: Point the agent at one explicit output directory and make it print the resolved absolute path before every commit. Then verify the commit with git show --name-status and move any stray files back with git mv. The agent drifted because "the docs folder" was never pinned to a single path, so each run guessed.