Czy powinienem .npmignore moje testy?

Co dokładnie powinienem włożyć .npmignore?

Testy? Rzeczy lubią .travis.yml, .jshintrc? Coś, co nie jest potrzebne podczas uruchamiania modułu (z wyjątkiem pliku readme)?

Nie mogę znaleźć żadnych wskazówek na ten temat.

Jak zapewne zauważyłeś, NPM tak naprawdę nie określa dokładnie, co powinno tam być, raczej ma listę ignorowanych domyślnie plików . Wiele osób nawet go nie używa, ponieważ wszystko w twoim .gitignorejest npmdomyślnie ignorowane, jeśli .npmignorenie istnieje. Ponadto wiele plików jest już domyślnie ignorowanych, niezależnie od ustawień, a niektóre pliki są zawsze wykluczane z ignorowania, jak opisano w powyższym łączu.

Nie ma zbyt wiele oficjalnych informacji na temat tego, co zawsze powinno tam być, ponieważ jest to w zasadzie podzbiór .gitignore, ale z tego, co wyciągam z używania node przez 5 lat, oto, co wymyśliłem.

Uwaga: Przez produkcję rozumiem każdą chwilę, w której twój moduł jest używany przez kogoś i nie rozwija się na samym module.

Skompilowane krzyżowo źródła w wersji wstępnej

• Zalety : Jeśli używasz języka, który kompiluje krzyżowo do JavaScript, możesz prekompilować przed wydaniem i nie dołączać .coffeeplików do pakietu, ale śledzić je w repozytorium git.

Zbuduj resztki plików

• Zalety : ludzie używający rzeczy takich jak node-gypmogą mieć pliki obiektów, które są generowane podczas kompilacji, które nigdy nie powinny trafiać do pakietu.
• Wady : To i tak powinno zawsze wchodzić w .gitignoregrę. Musisz umieścić te rzeczy w tym miejscu, jeśli używasz .npmignorejuż pliku, ponieważ zastępuje on .gitignorez punktu widzenia npm.

Testy

• Zalety : mniej bagażu w kodzie produkcyjnym.
• Wady : nie można uruchamiać testów w środowiskach na żywo, jeśli istnieje niewielka szansa na awarię specyficzną dla systemu, na przykład nieaktualną wersję uruchomionego węzła, która powoduje niepowodzenie testu.

Ustawienia ciągłej integracji / pliki meta

• Plusy : znowu mniej bagażu. Rzeczy, .travis.ymlktóre nie są wymagane do używania, testowania lub przeglądania kodu.

Dokumenty i przykłady kodu inne niż readme

• Plusy : mniej bagażu. Niektórzy ludzie istnieją w szkole myślenia, w której jeśli nie możesz wyrazić przynajmniej minimalnej użytecznej funkcjonalności w swoim pliku Readme, Twój moduł jest za duży.
• Wady : ludzie nie widzą wyczerpującej dokumentacji i przykładów kodu we własnym systemie plików. Musieliby odwiedzić repozytorium (co również wymaga połączenia z Internetem).

Obiekty stron Github

• Zalety : Z pewnością nie musisz zaśmiecać swoich wydań CNAMEplikami lub symbolami zastępczymi, index.htmljeśli używasz modułu, który służy gh-pagesrównież jako repozytorium.

bower.json i przyjaciele

• Zalety : jeśli zdecydujesz się zbudować swoje zależności przed wydaniem, nie potrzebujesz użytkownika końcowego, aby zainstalować bower, a następnie zainstalować więcej rzeczy. Osobiście trzymałbym te rzeczy w paczce. Kiedy robię npm install, powinienem polegać tylko na npm i żadnych innych zewnętrznych źródłach.

Zasadniczo powinieneś go używać, jeśli jest coś, co chcesz trzymać z dala od pakietu npm, ale nie z repozytorium npm. Nie jest to długa lista elementów, ale npm wolałby raczej wbudować funkcjonalność niż trzymać ludzi w swoich pakietach z nieistotnymi obiektami.

Zgadzam się z odpowiedzią krótkim i syntetic lante za i dużym odpowiedź Samt za :

• Nie powinieneś dołączać swoich testów do pakietu.
• Twój pakiet powinien zawierać tylko produkcyjne pliki wykonawcze.
• Dzięki temu paczka będzie prostsza i szybsza do pobrania.

Mój wkład w te odpowiedzi:

.npmignore to czarna lista umożliwiająca wybór pliku pakietu. Ale w bardziej praktyczny sposób możesz umieścić na białej liście pliki, które musisz uwzględnić w swoim pakiecie, używając pola plików w pliku package.json:

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

Myślę, że to prostsze, przyszłościowe i ma lepszą semantykę;)

Dla wyjaśnienia, za każdym razem, gdy ktoś to zrobi npm install your-library, npm pobierze wszystkie pliki źródłowe zawarte w repozytorium, z wyjątkiem plików, które umieścisz w swoim .npmignore.

Wiedz, że osoby instalujące Twoją bibliotekę będą potrzebowały tylko Twojej biblioteki, nic innego nie będzie konieczne.

Na przykład, gdy ktoś instaluje bibliotekę, prawdopodobnie nie dba o twoje .travis.ymllub twoje .jshintrcpliki, a nawet niektóre obrazy, pliki Grunt, dokumentację itp.

.npmignore może pozwolić, aby Twój pakiet npm miał mniej plików i był szybszy do pobrania

Nie dołączaj swoich testów. Często testy są około 5 razy większe niż rzeczywista baza kodu. Dopóki twoje testy są na Githubie itp., To wystarczy.

Ale to, co absolutnie powinieneś zrobić, to przetestować swój pakiet NPM w opublikowanym formacie . Utwórz kilka testów dymnych, które znajdują się w rzeczywistej bazie kodu, ale nie są częścią zestawu testów.

Możesz przeczytać o testowaniu swojego pakietu po jego utworzeniu w archiwum, tutaj: https://github.com/ORESoftware/r2g

Jak przetestować wynik „npm opublikuj” bez faktycznego publikowania go w NPM?