Skip to content

fix: stop the plugin update guard firing on npm install artifacts - #267

Open
ankitranjan7 wants to merge 1 commit into
mainfrom
fix/265-plugin-update-install-artifacts
Open

fix: stop the plugin update guard firing on npm install artifacts#267
ankitranjan7 wants to merge 1 commit into
mainfrom
fix/265-plugin-update-install-artifacts

Conversation

@ankitranjan7

Copy link
Copy Markdown
Contributor

Found while checking a failing test on #266 — unrelated to that PR, so it's on its own branch.

Problem

plugin install runs npm install --omit=dev --ignore-scripts in the cloned checkout (src/plugin.ts). A plugin repo without a .gitignore then reports node_modules/ and package-lock.json as untracked, and the dirty-checkout guard refuses to update:

$ webcmd plugin install github:rishabhraj36/webcmd-plugin-bookmyshow
✅ Plugin "bookmyshow" installed successfully.
$ webcmd plugin update bookmyshow
Error: Plugin "bookmyshow" has uncommitted changes that updating would destroy:
  node_modules/ (new, unstaged)
  package-lock.json (new, unstaged)

The guard fires on webcmd's own output and blames the user for work they never did. Any such plugin is permanently un-updatable short of --force, which is documented as "discard uncommitted changes" — a scary flag for a clean checkout. getDirtyFiles' doc comment assumed git status would never surface node_modules because it is gitignored; that only holds when the plugin repo ships a .gitignore.

This is what fails tests/e2e/plugin-management.test.ts > plugin update succeeds on an installed plugin on main.

Change

  • getDirtyFiles drops node_modules/ and package-lock.json at any depth — depth matters because monorepo installs run npm install at the repo root and in each sub-plugin.
  • Porcelain path parsing extracted into dirtyEntryPath, shared with describeDirtyEntry.
  • Everything else untracked is still real user work and still blocks the update. A file merely named like an artifact (node_modules_notes.md) still blocks; there's a test for that.

Not filtered: the .js files transpilePluginTs emits next to .ts sources. Those are indistinguishable from hand-written user files, and failing closed is the right default there.

Verification

npx vitest run405 files, 4854 passed, 1 skipped, 0 failed (the E2E now passes). npm run typecheck clean. Also verified by hand: install → update against the real bookmyshow plugin now succeeds.

🤖 Generated with Claude Code

`plugin install` runs `npm install` in the checkout, so a plugin repo without
a .gitignore reports node_modules/ and package-lock.json as untracked. The
dirty-checkout guard then refused every update — blaming the user for work
webcmd itself created, and leaving such plugins permanently un-updatable
short of --force.

getDirtyFiles now drops those paths (at any depth, covering monorepo
sub-plugin installs) before the guard decides. Anything else untracked is
still real user work and still blocks. Fixes the plugin-management E2E.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown
Contributor

🟢 No documentation gap found — medium confidence

The automated review found no documentation gap in the supplied changes.

This review is advisory and does not block merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant