pastilhasandClaude Fable 5
6071ded175
TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with frontmatter carrying id, status, created date and order, and the prose body copied across verbatim. TODO.md becomes a generated index (bun run todo:index). Dates: where an item's prose stated one it is used; otherwise its old section's; otherwise 2026-08-20, floored at the day before the split rather than invented. date_source records which. Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is the identity, frontmatter is the machine's half and the body is the owner's. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
29 lines
1.6 KiB
Markdown
29 lines
1.6 KiB
Markdown
---
|
|
id: plugin-system/a-plugin-cannot-declare-its-own-npm
|
|
title: "A plugin cannot declare its own npm dependencies, so the PLATFORM is carrying them"
|
|
theme: plugin-system
|
|
status: open
|
|
created: 2026-08-18
|
|
date_source: section
|
|
order: 1
|
|
---
|
|
|
|
**A plugin cannot declare its own npm dependencies, so the PLATFORM is carrying them.** `imapflow`,
|
|
`mailparser` and `@types/mailparser` are in the platform's `package.json` and are imported by nothing
|
|
in `src/` — they exist solely for `plugins/email/sidecar/`. Plugins have no `package.json`, run with
|
|
`cwd: PLATFORM_DIR`, and resolve from the platform's `node_modules`, so deleting those three lines
|
|
breaks the installed plugin on its first sync.
|
|
|
|
This does not scale and it is the wrong party holding the risk: the platform cannot be answerable for
|
|
what an arbitrary plugin decides to install, and `bunfig.toml` sets `frozenLockfile = true` precisely
|
|
so a dependency change is a deliberate, reviewed act. Publishing will be reviewed rather than a
|
|
free-for-all, which narrows the threat but does not move the responsibility.
|
|
|
|
What it probably needs: a `dependencies` field in the manifest (the manifest already holds
|
|
`osDependencies` for host binaries, which is the same shape of problem solved once), installed into
|
|
the plugin's own directory at install time rather than merged into the platform's tree. Note the
|
|
install path already learned not to trust `$PATH` — `pushPluginSchema` resolves a binary rather than
|
|
spawning `bunx` — so whatever runs the install has to do the same.
|
|
|
|
Until then: `imapflow` and `mailparser` STAY. Removing them is not tidying, it is breaking email.
|