Bonjour !
Une question rapide avant que je commence à construire. Il y a déjà un [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio) sur npm (v0.6.0, auteur différent) mais il a une dépendance d’exécution qui le rend non vérifiable et il ne peut pas être installé sur n8n Cloud. Le nœud entier est généré automatiquement à partir d’une spécification OpenAPI groupée via cette dépendance, donc la supprimer signifierait essentiellement le réécrire à partir de zéro de toute façon.
Je prévois de construire une version correcte, entièrement artisanale, sous ma propre identité npm : opérations déclaratives, test des identifiants, liste déroulante d’objets dynamique, zéro dépendance d’exécution. Mais les directives disent « s’il s’agit d’une itération, ouvrez une PR à la place ».
Un paquet tout neuf est-il le bon chemin ici compte tenu du fait que celui qui existe est architecturalement non vérifiable, ou dois-je utiliser la route PR de toute façon ? L’objectif du mien est qu’il soit approuvé par n8n et ajouté en tant que module communautaire public.
Merci !
@nodrel-dev un nouveau package est le bon choix. zéro dépendance runtime est absolument nécessaire pour les nœuds vérifiés, donc ce nœud de dépendance openapi auto-généré ne peut pas être vérifié, et aucune PR ne corrige ça sans la réécriture complète que tu décris.
la ligne « itération → PR » concerne l’amélioration d’un nœud maintenu, pas une reconstruction ex nihilo, une version zéro-dépendance entièrement réalisée à la main sous ta propre identité est un nouveau nœud, pas une itération de la leur. publie sous ton nom, ne réutilise pas n8n-nodes-attio.
comme l’équipe de vérification décide, note dans ta soumission que le nœud existant est incompatible avec le cloud en raison d’une dépendance runtime et que le tien est une reconstruction indépendante et non un fork. cela évite le signal d’alarme « n’y en a-t-il pas déjà un ».
Merci pour cet éclairage ! J’apprécie beaucoup.
De rien ! Fais-moi savoir si ça fonctionne ! Si c’est le cas, n’hésite pas à marquer l’une des réponses comme solution, sinon dis-moi et on peut essayer une autre idée !
Bienvenue @nodrel-dev ! J’ai suivi ce processus moi-même - un package neuf est définitivement le bon choix.
Quelques conseils pratiques pour passer la vérification : premièrement, exécutez npm install --production localement et vérifiez qu’il n’y a absolument aucun élément dans node_modules - l’équipe vérifie cela directement. Deuxièmement, incluez un fichier credentials/YourServiceApi.credentials.ts avec un test de credential approprié, même si c’est juste un simple GET vers un endpoint /me - les nœuds vérifiés sans tests de credential ont tendance à être signalés. Troisièmement, la collision de nom avec n8n-nodes-attio pourrait être soulevée lors de l’examen, donc ayez une brève explication prête dans votre note de soumission (que achamm a déjà suggérée).