你好！
在我開始構建之前有個快速問題。npm 上已經有一個 [n8n-nodes-attio](https://www.npmjs.com/package/n8n-nodes-attio)（v0.6.0，不同的作者），但它有一個運行時依賴項，這使得它無法驗證，也無法在 n8n Cloud 上安裝。整個節點是通過該依賴項從捆綁的 OpenAPI 規格自動生成的，所以移除它基本上意味著從頭開始重寫。
我計劃在我自己的 npm 身份下構建一個適當的手工製作版本：聲明式操作、憑證測試、動態對象下拉列表、零運行時依賴項。但指南說「如果是迭代，改為開啟 PR」。
考慮到現有的版本在架構上無法驗證，新的軟件包是正確的途徑嗎？還是無論如何我都需要走 PR 路線？我的目標是讓它被 n8n 批准並作為公開社區模塊添加。
謝謝！
@nodrel-dev 推出全新套件是正確的做法。零執行時相依性對於驗證節點來說是絕對必要的，所以那個自動產生的 openapi-dep 節點無法驗證，沒有 PR 能在不進行你所描述的完整重寫的情況下解決這個問題。
「迭代 → PR」這條線是用於改進已維護的節點，而不是全新重建，一個零相依性手工製作的版本歸在你自己的名義下是一個新節點，而不是他們節點的迭代。以你自己的名義發布，不要重複使用 n8n-nodes-attio。
由於驗證團隊會做決定，請在你的提交中記錄現有節點在執行時相依性方面與雲端不相容，以及你的是獨立重建而非分叉。這樣可以避免「不是已經有一個了嗎」這個標籤。
感謝你的見解！我很感謝
歡迎！讓我知道是否有效！如果有效，請隨時給其中一個回覆按心形表示是解決方案，如果沒有的話告訴我，我們可以試試另一個想法！
歡迎 @nodrel-dev！我自己也經歷過這個流程 - 使用全新套件絕對是正確的選擇。
通過驗證的幾個實用建議：首先，在本機上執行 npm install --production 並驗證 node_modules 中絕對沒有任何項目 - 團隊會直接檢查這部分。其次，包含一個 credentials/YourServiceApi.credentials.ts 檔案，其中包含適當的憑證測試，即使只是對 /me 端點進行簡單的 GET 請求 - 沒有憑證測試的已驗證節點往往會被標記。第三，與 n8n-nodes-attio 的名稱衝突可能會在審查中出現，所以在提交說明中準備好簡短的解釋（achamm 已經建議過）。