All skillsBan the "overrides" field in community node package.json (
Skillintermediate
Ban the "overrides" field in community node package.json (`@n8n/community-nodes/no-overrides-field`)
š¼ This rule is enabled in the following configs: ā `recommended`, āļø `recommendedWithoutN8nCloudSupport`.
Claude Code Knowledge Pack7/10/2026
Overview
Ban the "overrides" field in community node package.json (@n8n/community-nodes/no-overrides-field)
š¼ This rule is enabled in the following configs: ā
recommended, āļø recommendedWithoutN8nCloudSupport.
Rule Details
The overrides field in package.json lets a package force specific versions of its (transitive) dependencies. In the context of n8n community nodes this is dangerous:
- Community nodes are installed into a shared n8n runtime alongside other nodes. Overriding a shared library (e.g.
axios,@langchain/core,minimatch) can silently substitute an incompatible version for every other node that depends on it, causing hard-to-diagnose runtime failures. - Community nodes are distributed as pre-built packages with their dependencies already bundled or declared as
peerDependencies. Any version pinning that the node actually needs should happen during development, not at install time on the user's n8n instance. overridesis frequently copy-pasted from an unrelated internal project and is almost never intentional in a community node.
If you have a genuine compatibility need, bundle the dependency into the published artifact or declare it via peerDependencies instead.
Examples
Incorrect
{
"name": "n8n-nodes-example",
"overrides": {
"axios": "1.7.0"
}
}
{
"name": "n8n-nodes-example",
"overrides": {
"axios": "1.7.0",
"@langchain/core": "0.3.0",
"minimatch": "9.0.5"
}
}
Correct
{
"name": "n8n-nodes-example",
"peerDependencies": {
"n8n-workflow": "*"
}
}