While auditing the published package tarball for this project (as part of a broader pass over dependency hygiene across my n8n community node packages), I found three dependencies that appear to be entirely dead weight:
keyv@^4.5.3reflect-metadata@types/reflect-metadata
All three appear only in package.json. There's no require('keyv'), no require('reflect-metadata'), and no equivalent import for either anywhere in the actual dist output. As far as I can tell they were either pulled in during early scaffolding and never wired up, or left over from a removed feature.
Recommendation
Remove all three. There's no functional risk since nothing in the shipped code references them.
Secondary benefit
This package's keyv@^4.5.3 pin also contributes to a dependency-version split I've been chasing across my n8n community node packages: in shared n8n community-node environments, this package and others of mine (n8n-nodes-autotask, n8n-nodes-crawl4ai-plus) end up sharing a single node_modules tree, and some of those packages pin keyv@^5 while this one pins keyv@^4. That forces npm to maintain a dual-major-version tree for keyv whenever anything in the shared tree gets installed or updated — a more fragile resolution operation than it needs to be. Removing this dead dependency eliminates this package's contribution to that split for free, since it's unused anyway.
For platform-level context on why that version-split fragility matters in queue-mode n8n deployments specifically, see n8n-io/n8n#30533 (community-package pubsub broadcast causes every worker to independently attempt the same install/reinstall concurrently, turning ordinary dependency-resolution complexity into an actual race).
Related: msoukhomlinov/n8n-nodes-autotask (linked below once filed — same keyv-version-split investigation).
While auditing the published package tarball for this project (as part of a broader pass over dependency hygiene across my n8n community node packages), I found three dependencies that appear to be entirely dead weight:
keyv@^4.5.3reflect-metadata@types/reflect-metadataAll three appear only in
package.json. There's norequire('keyv'), norequire('reflect-metadata'), and no equivalentimportfor either anywhere in the actualdistoutput. As far as I can tell they were either pulled in during early scaffolding and never wired up, or left over from a removed feature.Recommendation
Remove all three. There's no functional risk since nothing in the shipped code references them.
Secondary benefit
This package's
keyv@^4.5.3pin also contributes to a dependency-version split I've been chasing across my n8n community node packages: in shared n8n community-node environments, this package and others of mine (n8n-nodes-autotask,n8n-nodes-crawl4ai-plus) end up sharing a singlenode_modulestree, and some of those packages pinkeyv@^5while this one pinskeyv@^4. That forces npm to maintain a dual-major-version tree for keyv whenever anything in the shared tree gets installed or updated — a more fragile resolution operation than it needs to be. Removing this dead dependency eliminates this package's contribution to that split for free, since it's unused anyway.For platform-level context on why that version-split fragility matters in queue-mode n8n deployments specifically, see n8n-io/n8n#30533 (community-package pubsub broadcast causes every worker to independently attempt the same install/reinstall concurrently, turning ordinary dependency-resolution complexity into an actual race).
Related: msoukhomlinov/n8n-nodes-autotask (linked below once filed — same keyv-version-split investigation).