Verification question: existing node has a runtime dep that blocks it — does a fresh package qualify?

Hello!

Quick question before I start building. There’s already an [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio) on npm (v0.6.0, different author) but it has a runtime dependency that makes it unverifiable and it can’t be installed on n8n Cloud. The whole node is auto-generated from a bundled OpenAPI spec through that dep, so removing it would basically mean rewriting it from scratch anyway.

I’m planning to build a proper hand-crafted version under my own npm identity: declarative operations, credential test, dynamic object dropdown, zero runtime deps. But the guidelines say “if it’s an iteration, open a PR instead.”

Is a fresh package the right path here given the existing one is architecturally unverifiable, or do I need to go the PR route regardless? The goal for mine is to have it approved by n8n and added as a public community module.

Thank you!

@nodrel-dev fresh package is the right call. zero runtime deps is absolute for verified nodes, so that auto-generated openapi-dep node cant be verified, and no PR fixes that without the full rewrite youre describing.

the “iteration → PR” line is for improving a maintained node, not a clean-room rebuild, a zero-dep hand-crafted version under your own identity is a new node, not an iteration of theirs. publish under your own name, dont reuse n8n-nodes-attio.

since the verification team decides, note in your submission that the existing node is cloud-incompatible from a runtime dep and yours is an independent rebuild not a fork. heads off the “isnt there already one” flag.

Thank you for the insight! I appreciate it

Your welcome! Let me know if it works! If it does, feel free to heart one of the replies as the solution, if not lemme know and we can try another idea!

Welcome @nodrel-dev! Went through this process myself - fresh package is definitely the right call.

A few practical tips for going through verification: first, run npm install --production locally and verify there are absolutely zero items in node_modules - the team checks this directly. Second, include a credentials/YourServiceApi.credentials.ts file with a proper credential test even if it’s just a simple GET to a /me endpoint - verified nodes without credential tests tend to get flagged. Third, the name collision with n8n-nodes-attio might come up in review, so have a short explanation ready in your submission note (which achamm already suggested).