Uma pergunta rápida antes de começar. Já existe um [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio) no npm (v0.6.0, de um autor diferente), mas ele tem uma dependência de runtime que o torna não verificável e não pode ser instalado no n8n Cloud. Todo o nó é gerado automaticamente a partir de uma especificação OpenAPI agrupada através dessa dependência, então removê-la significaria basicamente reescrevê-lo do zero mesmo assim.
Estou planejando construir uma versão adequada, feita manualmente, sob minha própria identidade no npm: operações declarativas, teste de credencial, dropdown de objeto dinâmico, zero dependências de runtime. Mas as diretrizes dizem “se for uma iteração, abra um PR em vez disso”.
Um pacote novo é o caminho certo aqui, dado que o existente é arquitetonicamente não verificável, ou preciso seguir a rota de PR independentemente? O objetivo do meu é ter a aprovação do n8n e ser adicionado como um módulo comunitário público.
@nodrel-dev pacote novo é a escolha certa. zero dependências em runtime é essencial para nós verificados, então esse nó openapi-dep auto-gerado não pode ser verificado, e nenhum PR resolve isso sem a reescrita completa que você tá descrevendo.
a linha “iteração → PR” é para melhorar um nó mantido, não uma reconstrução do zero, uma versão zero-dep feita à mão sob sua própria identidade é um nó novo, não uma iteração do deles. publique sob seu próprio nome, não reutilize n8n-nodes-attio.
já que o time de verificação decide, anote na sua submissão que o nó existente é incompatível com cloud por causa da dependência em runtime e o seu é uma reconstrução independente, não um fork. isso evita a flag “não existe já um?”.
De nada! Me avisa se funciona! Se funcionar, fica à vontade para marcar uma das respostas como solução, se não funcionar me conta e a gente tenta outra ideia!
Bem-vindo @nodrel-dev! Passei por esse processo eu mesmo - um pacote novo é definitivamente a escolha certa.
Algumas dicas práticas para passar pela verificação: primeiro, execute npm install --production localmente e verifique se há absolutamente zero itens em node_modules - o time verifica isso diretamente. Segundo, inclua um arquivo credentials/YourServiceApi.credentials.ts com um teste de credencial apropriado, mesmo que seja apenas um GET simples para um endpoint /me - nós verificados sem testes de credencial tendem a ser sinalizados. Terceiro, a colisão de nome com n8n-nodes-attio pode surgir na revisão, então tenha uma explicação breve pronta na sua nota de submissão (que achamm já sugeriu).