Sollte ich meine Tests .npmignore?

Was genau soll ich eingeben .npmignore?

Tests? Sachen wie .travis.yml, .jshintrc? Was wird beim Ausführen des Moduls nicht benötigt (außer der Readme-Datei)?

Ich kann hierzu keine Anleitung finden.

Wie Sie wahrscheinlich festgestellt haben, gibt NPM nicht genau an, was dort hineingelangen soll, sondern enthält eine Liste von standardmäßig ignorierten Dateien . Viele Leute benutzen es nicht einmal, da alles in Ihrem standardmäßig .gitignoreignoriert npmwird, wenn .npmignorees nicht existiert. Darüber hinaus werden viele Dateien unabhängig von den Einstellungen bereits standardmäßig ignoriert, und einige Dateien werden immer vom Ignorieren ausgeschlossen, wie im obigen Link beschrieben.

Es gibt nicht viel Offizielles darüber, was immer da sein sollte, da es sich im Grunde genommen um eine Teilmenge von handelt .gitignore, aber von dem, was ich aus der Verwendung von Node für 5 Jahre gewonnen habe, habe ich mir Folgendes ausgedacht.

Hinweis: Mit Produktion meine ich jede Zeit, in der Ihr Modul von jemandem verwendet wird und nicht auf dem Modul selbst entwickelt wird.

Cross-kompilierte Quellen vor der Veröffentlichung

• Vorteile : Wenn Sie eine Sprache verwenden, die in JavaScript überkompiliert wird, können Sie diese vor der Veröffentlichung vorkompilieren und keine .coffeeDateien in Ihr Paket aufnehmen, sondern sie weiterhin in Ihrem Git-Repository verfolgen.

Erstellen Sie Dateireste

• Vorteile : Benutzer, die Dinge wie node-gypverwenden, haben möglicherweise Objektdateien, die während eines Builds generiert werden und niemals in das Paket aufgenommen werden sollten.
• Nachteile : Dies sollte .gitignoresowieso immer in die gehen . Sie müssen diese Dinge hier einfügen, wenn Sie .npmignorebereits eine Datei verwenden, da diese .gitignoreaus Sicht von npm überschrieben wird .

Tests

• Vorteile : Weniger Gepäck in Ihrem Produktionscode.
• Nachteile : Sie können keine Tests in Live-Umgebungen ausführen, wenn die Wahrscheinlichkeit gering ist, dass ein systemspezifischer Fehler auftritt, z. B. eine veraltete Version des Knotens, die ausgeführt wird und dazu führt, dass ein Test fehlschlägt.

Kontinuierliche Integrationseinstellungen / Metadateien

• Vorteile : Wieder weniger Gepäck. Dinge, .travis.ymldie zum Verwenden, Testen oder Anzeigen des Codes nicht erforderlich sind.

Nicht Readme-Dokumente und Codebeispiele

• Vorteile : Weniger Gepäck. Es gibt einige Leute in der Denkschule, bei denen Ihr Modul zu groß ist, wenn Sie in Ihrer Readme-Datei nicht mindestens die Mindestfunktionalität ausdrücken können.
• Nachteile : Benutzer können keine ausführliche Dokumentation und Codebeispiele in ihrem eigenen Dateisystem sehen. Sie müssten das Repository besuchen (für das auch eine Internetverbindung erforderlich ist).

Github-Seitenobjekte

• Vorteile : Sie müssen Ihre Veröffentlichungen sicherlich nicht mit CNAMEDateien oder Platzhaltern verunreinigen, index.htmlwenn Sie Ihr Modul verwenden, das auch als gh-pagesRepository dient .

bower.json und Freunde

• Vorteile : Wenn Sie Ihre Abhängigkeiten vor der Veröffentlichung einbauen möchten, muss der Endbenutzer bower nicht installieren, sondern weitere Dinge damit installieren. Ich persönlich würde das Zeug im Paket behalten. Wenn ich eine mache npm install, sollte ich mich nur auf npm und keine anderen externen Quellen verlassen.

Grundsätzlich sollten Sie es immer verwenden, wenn Sie etwas aus Ihrem npm-Paket heraushalten möchten, aber nicht aus Ihrem npm-Repository. Es ist keine lange Liste von Elementen, aber npm würde lieber die Funktionalität einbauen, als dass Leute mit irrelevanten Objekten in ihrem Paket stecken bleiben.

Ich stimme der kurzen und syntetischen Antwort von Lante und der großen Antwort von SamT zu :

• Sie sollten Ihre Tests nicht in Ihr Paket aufnehmen.
• Ihr Paket sollte nur Produktionslaufzeitdateien enthalten.
• Dadurch wird Ihr Paket einfacher und schneller heruntergeladen.

Mein Beitrag zu diesen Antworten:

.npmignore ist die Blacklist- Methode zur Auswahl von Paketdateien. Aber in einer praktischeren Weise können Sie die weiße Liste setzen Sie in Ihrem Paket - Dateien müssen schließen mit dem Datei Feld in Ihrem package.json:

{
  "files": [
    "lib/",
    "index.js"
  ]
}

Ich denke das ist einfacher, zukunftssicher und hat eine bessere Semantik;)

Zur Verdeutlichung lädt npm jedes Mal , wenn jemand dies tut npm install your-library, alle Quelldateien herunter, die das Repo enthält, mit Ausnahme der Dateien, die Sie in Ihr Repo aufnehmen ..npmignore

Wissen Sie, dass Leute, die Ihre Bibliothek installieren, nur Ihre Bibliothek ausführen müssen, alles andere ist nicht erforderlich.

Wenn zum Beispiel jemand eine Bibliothek installiert, ist es wahrscheinlich, dass er sich nicht um Ihre .travis.ymloder Ihre .jshintrcDateien oder sogar um einige Bilder, Grunt-Dateien, Dokumentationen usw. kümmert .

.npmignore könnte dazu führen, dass Ihr npm-Paket weniger Dateien enthält und schneller heruntergeladen werden kann

Schließen Sie Ihre Tests nicht ein. Oft sind Tests etwa 5x so groß wie die eigentliche Codebasis. Solange Ihre Tests auf Github usw. durchgeführt werden, ist das gut genug.

Was Sie jedoch unbedingt tun sollten, ist, Ihr NPM-Paket in seinem veröffentlichten Format zu testen . Erstellen Sie einige Rauchtests, die sich in der eigentlichen Codebasis befinden, aber nicht Teil der Testsuite sind.

Informationen zum Testen Ihres Pakets nach dem Tarballing finden Sie hier: https://github.com/ORESoftware/r2g

Wie kann man ein "npm Publish" -Ergebnis testen, ohne es tatsächlich in NPM zu veröffentlichen?