¡Hola!
Una pregunta rápida antes de empezar a construir. Ya existe un [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio) en npm (v0.6.0, de un autor diferente) pero tiene una dependencia de tiempo de ejecución que lo hace no verificable y no se puede instalar en n8n Cloud. Todo el nodo se genera automáticamente a partir de una especificación OpenAPI agrupada a través de esa dependencia, así que eliminarla significaría básicamente reescribirlo desde cero de todas formas.
Tengo planeado construir una versión adecuada hecha a mano bajo mi propia identidad en npm: operaciones declarativas, prueba de credenciales, menú desplegable de objeto dinámico, cero dependencias de tiempo de ejecución. Pero las directrices dicen “si es una iteración, abre un PR en su lugar”.
¿Es un paquete nuevo el camino correcto aquí dado que el existente es arquitectónicamente no verificable, o necesito seguir la ruta del PR de todas formas? Mi objetivo es que sea aprobado por n8n y agregado como un módulo comunitario público.
¡Gracias!
@nodrel-dev el paquete nuevo es la decisión correcta. cero dependencias en tiempo de ejecución es absoluto para nodos verificados, así que ese nodo openapi-dep generado automáticamente no puede verificarse, y ningún PR soluciona eso sin la reescritura completa que describes.
la línea “iteración → PR” es para mejorar un nodo mantenido, no una reconstrucción sin referencias, una versión hecha a mano sin dependencias bajo tu propia identidad es un nodo nuevo, no una iteración del suyo. publica bajo tu propio nombre, no reutilices n8n-nodes-attio.
ya que el equipo de verificación decide, anota en tu envío que el nodo existente es incompatible con la nube por una dependencia en tiempo de ejecución y el tuyo es una reconstrucción independiente, no una bifurcación. eso evita la bandera “¿no hay ya uno”.
¡Gracias por la perspectiva! Lo aprecio
¡De nada! ¡Cuéntame si funciona! Si es así, no dudes en marcar una de las respuestas como solución, ¡y si no funciona, avísame y podemos probar otra idea!
¡Bienvenido @nodrel-dev! Ya pasé por este proceso — un paquete nuevo es definitivamente la opción correcta.
Algunos consejos prácticos para pasar la verificación: primero, ejecuta npm install --production localmente y verifica que no haya absolutamente nada en node_modules — el equipo lo comprueba directamente. Segundo, incluye un archivo credentials/YourServiceApi.credentials.ts con una prueba de credencial adecuada aunque sea solo un GET simple a un endpoint /me — los nodos verificados sin pruebas de credenciales tienden a ser marcados. Tercero, la colisión de nombres con n8n-nodes-attio podría surgir en la revisión, así que ten una breve explicación lista en la nota de envío (que achamm ya sugirió).