Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

plugin add/remove: nothing records what an install created, so the undo and the uninstall both guess

Đã đóng
  • Có gì không ổn?
#98 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Một pull request liên quan đã được merge.

  • #102 của @MatAtBread — đã đóng, không merge
  • #103 của @MatAtBread — đã merge

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
12/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, typescript
Lĩnh vực
tooling

Hướng nghiên cứu

Start with the plugin add and plugin remove paths that write matbot.yaml, the root package.json key, .plugins/node_modules/<name> and .plugins/.restore/, and with readDependencyNames, which the payload says both paths share. Reproduce one add then remove on the npm route and list what remains under .plugins/. Done when a per-plugin install record drives both the undo and remove, and add then remove leaves nothing add created. Open PR #103 already targets this, so coordinate with it before starting.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

Summary

plugin add creates things in up to six places depending on the route: a package.json key, node_modules, .plugins/<host>/…, a .plugins/node_modules/<name> self-link, dependencies installed into a cache directory or a local checkout, and .plugins/.restore/. Nothing records which of them a given install created. So remove, and the undo of an add that then disowns the plugin, both infer it from the state they find. Each fix to one inference has broken the other, and a live run shows remove leaving most of it behind.

These should be fixed together. They are two halves of one question: what did this install create, and who takes it back out?

Already known

The gap #90 left. On the npm route, an add that then disowns the plugin keeps the install. That happens on a duplicate name, an incompatible runtime, or "not a plugin". On a duplicate name config is never written, so remove has no entry to offer the uninstall against.

Two regressions in the attempted fix. The fix is in PR #93's commits (6d56bd1, 1f42280, never merged; #93 is closed in favour of this issue):

  1. readDependencyNames was widened to devDependencies and peerDependencies for the undo's before-snapshot. remove shares it, so plugin remove @x/foo now offers to pm remove a package the project declares only as a peer or dev dependency, deleting the project's own declaration.
  2. A new pre-install name-clash guard refuses plugin add [email protected] when foo is loaded. That removes the only in-tool way to change an npm plugin's version; before, the version changed on disk and a reload picked it up despite the clash error.

Found by a live add → reload → remove run

The run used @matatbread/matbot-email from github, a local path, npm and http. All four routes installed, reloaded and worked. remove cleans matbot.yaml and, for npm, the root package.json key and node_modules link, but leaves:

  1. The self-link .plugins/node_modules/@matatbread/matbot-email. It survives remove, so a removed plugin is still resolvable by bare name. It was repointed by whichever route installed last, and was left dangling at the end.
  2. The cached source and its installed dependencies. .plugins/raw.githubusercontent.com/MatAtBread/matbot-email/ kept HEAD/, main/ and refs/heads/main/, each with src/ and a full node_modules (imapflow, mailparser, nodemailer, …). Each spelling of the same repo is a separate cache directory that is never reclaimed; main/ held an older revision.
  3. Empty .plugins/.restore/… directories left behind after discardRestore.
  4. The host's pnpm-lock.yaml rewritten. After the npm cycle the lockfile had lost its catalogs: block, while package.json was back as it was. The node_modules/.pnpm entries also remain, though pruning those is arguably pnpm's job.
  5. Local route: installing dependencies writes node_modules and package-lock.json into the user's checkout. That is by design, but remove never mentions it.

Suggested direction

Use the same shape as the #89 fix (#97): state it instead of deriving it. add would write an install record per plugin, saying which route it took, the dependency key it introduced into package.json (if any), the cache root, the self-link, and the dependency directories and lockfile it created. Both the undo-on-disown and remove would replay that record and act on nothing else, with nothing inferred from the specifier or a manifest diff. Changing an installed plugin's version would become an explicit operation rather than a side effect of the clash path.

Done when

  • For every route, add → remove leaves nothing that add created, unless remove was told to keep it.
  • A failed or disowned add leaves nothing behind.
  • Neither path ever touches a dependency that add did not introduce.
  • plugin add foo@<version> on a loaded foo has a defined, documented behaviour.
Ngôn ngữ chính
TypeScript
Star
5
Fork
2
Merge trung bình
1 ngày 2 giờ
Pull request đã merge (30 ngày)
12

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của MatAtBread/matbot

Tất cả issue của MatAtBread/matbot

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.