Hallo n8n-Team,
Ich betreue n8n-nodes-duckduckgo-search, einen anmeldungsfreien DuckDuckGo-Suchknoten mit etwa 21.000 Installationen. Ich möchte ihn zur Verifizierung einreichen und habe die Anforderungen gelesen, insbesondere die Regel „zero-runtime-dependency
Hey @Sam_Nodehi, während du auf eine Antwort wartest, könnten dir diese Ressourcen helfen:
Automatisch auf deine Frage abgestimmt.
Dokumentation:
Forum:
@Misha, @Baseman - ihr habt schon bei ähnlichen Problemen geholfen, könnt ihr mal einen Blick drauf werfen?
Automatisch vorgeschlagen von n8ns Community-Bot. Es ist ein Pilotprojekt – bitte teilt euer Feedback hier.
Ich habe mich kürzlich durch die Verifizierung gearbeitet, daher könnte einiges davon übertragbar sein, aber ich würde das mit dem n8n-Team doppelt prüfen. Behandle das als die Lesart eines Maintainers und nicht als eine verbindliche Aussage.
Bei der Abhängigkeitsregel würde ich vor einer Umschreibung klären, ob Bundling zählt. Die Einschränkung betrifft das, was npm zur Laufzeit auflöst und installiert, also das Vendoring deiner Abhängigkeiten in das veröffentlichte dist mit einem Bundler könnte das erfüllen, ohne Funktionalität zu verlieren. Wenn diese Lesart stimmt, bleiben Readability und linkedom dort, wo sie sind, und du vermeidest das Regressionsrisiko ganz. Das ist der Unterschied zwischen einer Build-Config-Änderung und einer Umschreibung, daher lohnt es sich, explizit nachzufragen, statt es einfach anzunehmen.
Personlich haben wir alle externen Deps entfernt, um verifiziert zu werden, und haben es stattdessen unsere APIs serverseitig nutzen lassen. Ein Nachteil ist, dass wir für unser beliebtes Paket GitHub - TurboDocx/html-to-docx: HTML to DOCX converter · GitHub Rechenzyklen dafür aufbringen müssten und es wahrscheinlich in unseren kostenpflichtigen Plan verschieben müssten.
Zu Frage 3, das Datacenter-IP-Problem: Die Tatsache, dass dein Node die Anomalie-Seite erkennt und explizit meldet, statt ein leeres Array zurückzugeben, ist das richtige Verhalten, und ich würde das oben in der Readme platzieren, statt einen Reviewer es entdecken zu lassen. Ein Reviewer, der das Rate Limit trifft und eine klare Meldung „DuckDuckGo hat eine Anomalie-Seite zurückgegeben
Danke, das war es wert, dem nachzugehen, denn wenn Bundling gezählt würde, würde das die ganze Entscheidung verändern. Ich habe es gemessen, anstatt darüber nachzudenken, und die Antwort lautet „ja, aber nicht für diese Bibliotheken
@Sam_Nodehi
@Nicolas_Fry gut gemacht!.. Ich würde auch die Endpunkt-Frage klären, bevor du das Rewrite machst. Da DuckDuckGo keine offizielle Search API bereitstellt, könnte die Test-Umgebung des Reviewers genauso wichtig sein wie der Node selbst. Für das Datacenter-/IP-Problem stimme ich zu, dass es eine gute Idee ist, die 202-Response und Anomalie-Behandlung explizit in der README zu dokumentieren. Das gibt dem Reviewer Kontext, anstatt einen fehlgeschlagenen Test wie einen kaputten Node aussehen zu lassen.
Und bezüglich der Abhängigkeitsanforderung würde ich definitiv bei n8n eine Bestätigung einholen, ob Bundling/Vendoring akzeptabel ist, bevor du readability und linkedom entfernst – das könnte dir eine Menge unnötige Rewrite-Arbeit sparen.
Danke @daniel_Samuel, und du hast recht, die Bundling-Frage auch nach meiner Messung noch zu stellen, denn die Messung beantwortet eine engere Frage, als es den Anschein hat.
Was ich etabliert habe, ist, was der Scanner tut: axios, @mozilla/readability und linkedom mit esbuild bündeln, @n8n/scan-community-package’s eigene Konfiguration auf die Ausgabe anwenden, und man erhält 125 Fehler. Alle stammen aus dem eigenen Code der Bibliotheken: process ×46, globalThis ×8, setTimeout ×15, plus require('stream'), require('util'), require('path').
Was es nicht etabliert, ist, ob dieses Urteil der Richtlinie entspricht. process innerhalb einer gebündelten Abhängigkeit ist nicht das Node „unter Verwendung eines eingeschränkten Globals
Aktualisierung: Version 32.17.0 ist verfügbar. „Extract Page Content