Verifizierungsfrage: Existierender Node hat eine Laufzeit-Abhängigkeit, die ihn blockiert — qualifiziert sich ein frisches Paket?

Hallo!

Eine kurze Frage, bevor ich anfange zu bauen. Es gibt bereits ein [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio) auf npm (v0.6.0, anderer Autor), aber es hat eine Runtime-Abhängigkeit, die es nicht verifizierbar macht und das es nicht auf n8n Cloud installiert werden kann. Der ganze Node wird automatisch aus einem gebündelten OpenAPI-Spec durch diese Abhängigkeit generiert, daher würde das Entfernen davon im Grunde bedeuten, ihn von Grund auf neu zu schreiben.

Ich plane, eine ordnungsgemäß handgefertigte Version unter meiner eigenen npm-Identität zu bauen: deklarative Operationen, Credential-Test, dynamisches Objekt-Dropdown, null Runtime-Abhängigkeiten. Aber die Richtlinien besagen „wenn es eine Iteration ist, öffne stattdessen einen PR."

Ist ein frisches Package der richtige Weg, da das vorhandene architektonisch nicht verifizierbar ist, oder muss ich ohnehin den PR-Weg gehen? Mein Ziel ist, dass es von n8n genehmigt wird und als öffentliches Community-Modul hinzugefügt wird.

Danke!

@nodrel-dev frisches Package ist der richtige Weg. Null Runtime-Abhängigkeiten sind absolut notwendig für verifizierte Nodes, also kann der automatisch generierte openapi-dep Node nicht verifiziert werden, und kein PR behebt das ohne den vollständigen Rewrite, den du beschreibst.

die Zeile „Iteration → PR

Danke für die Einsicht! Ich weiß das zu schätzen

Gerne! Lass mich wissen, ob es funktioniert! Falls ja, kannst du gerne eine der Antworten als Lösung markieren, falls nicht, sag mir Bescheid und wir versuchen eine andere Idee!

Willkommen @nodrel-dev! Ich bin diesen Prozess selbst durchgegangen - ein frisches Package ist definitiv die richtige Wahl.

Ein paar praktische Tipps für die Verifikation: Erstens, führe lokal npm install --production aus und verifiziere, dass absolut keine Items in node_modules vorhanden sind - das Team prüft das direkt. Zweitens, füge eine credentials/YourServiceApi.credentials.ts Datei mit einem ordentlichen Credentials-Test ein, auch wenn es nur ein einfaches GET zu einem /me Endpoint ist - verifizierte Nodes ohne Credentials-Tests werden oft markiert. Drittens, die Namenskollision mit n8n-nodes-attio könnte in der Review aufkommen, daher halte eine kurze Erklärung in deiner Submission-Note bereit (was achamm bereits vorgeschlagen hat).