dsh plugin add rewrites dsh.profile.bundles from dependencies, silently dropping undeclared bundles

[regrevia]

What happens

Running dsh plugin --profile <name> add <package> can leave a profile with fewer bundles than it had before, and with entries that no longer resolve on disk.

Observed shape:

• before: profile package.json → dsh.profile.bundles lists N bundles, including an out-of-tree plugin that is symlinked into the profile's node_modules (installed by hand, not a dependency of the profile manifest)
• run dsh plugin --profile <name> add <some-package>
• after: that hand-installed entry is gone from dsh.profile.bundles (the package is still present in node_modules), some other listed entry points at a package that is not in node_modules, and one newly named entry appears — all in one write, with the manifest mtime matching the install
• effect: next launch loads fewer plugins; the user has to re-add the dropped names by hand

Mechanism (from reading the shipped app)

The manifest sync rebuilds the list from package.json dependencies; for each dependency that declares dsh.bundle and is not disabled and not already listed, it appends the name, and writes the manifest back if the array changed:

if (dependency.bundle && !disabled.has(dependency.name) && !bundles.includes(dependency.name)) bundles.push(dependency.name);

That accounts for the write-back, and for dropping anything that is in node_modules but not in dependencies (out-of-tree / symlinked / alias installs). It does not by itself explain entries that name packages absent from node_modules.

Suggested fix

• Limit the write-back to the packages the operation actually touched; never rewrite unrelated entries in dsh.profile.bundles.
• When an entry cannot be resolved, keep it and report it (skippedBundles already exists) instead of rewriting the list around it, so failures stay visible and reversible.
• Log which entries were dropped, with the reason, instead of a silent manifest diff.

Rewriting the whole ordered load table as a side effect of installing one plugin is the dangerous part: a single install can change what the next launch loads.

[regrevia]

Second data point from another macOS machine, for scope:

• profile dsh.profile.bundles has 23 entries; every install-managed entry resolves under node_modules; no phantom entry and no dropped entry after plugin installs.
• dsh-unlag is present in both dependencies and bundles, so it survives the sync.
• The profile does have packages in dependencies but not in bundles — those are disabled plugins, which is the documented "disable keeps the dependency" behaviour.

So the rewrite itself looks intended; what looks fragile is the drop path: an entry that lives only in node_modules (hand-installed, symlinked, aliased) has no dependency record, so the recompute removes it. And the phantom entry in the original report suggests the write-back can also carry a name that no longer resolves.

Two asks, both cheap:

1. When the sync removes an entry, log it (name + reason) — the current silent manifest diff is what makes this hard to attribute.
2. Only touch entries the operation owns; leave unrelated entries alone even if they do not resolve.