---
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.