Должен ли я .npmignore мои тесты?

Ответ 1

Как вы, вероятно, обнаружили, NPM на самом деле не указывает, что именно должно происходить, скорее, у них есть список игнорируемых по умолчанию файлов. Многие люди даже не используют его, так как все в вашем .gitignore по умолчанию игнорируется в npm, если .npmignore не существует. Кроме того, многие файлы уже игнорируются по умолчанию независимо от настроек, а некоторые файлы всегда исключаются из списка игнорируемых, как указано в приведенной выше ссылке.

О том, что всегда должно быть там, не так уж много официального, потому что это, по сути, подмножество .gitignore, но из того, что я собрал при использовании узла в течение 5 лет, вот что я придумал.

Примечание: под производством я подразумеваю любое время, когда ваш модуль кем-то используется, а не разрабатывается на самом модуле.

Предварительно выпущенные кросс-скомпилированные источники

• Плюсы: если вы используете язык, который кросс-компилируется в JavaScript, вы можете прекомпилировать перед выпуском и не включать файлы .coffee в свой пакет, но продолжайте отслеживать их в своем git-репозитории.

Остатки файла сборки

• Плюсы: у людей, использующих такие вещи, как node-gyp могут быть объектные файлы, сгенерированные во время сборки, которые никогда не должны входить в пакет.
• Минусы: это всегда должно идти в .gitignore любом случае. Вы должны поместить эти вещи внутрь, если вы уже используете файл .npmignore как он переопределяет .gitignore с точки зрения npm.

тесты

• Плюсы: меньше багажа в вашем производственном коде.
• Минусы: вы не можете запускать тесты в реальных средах, поскольку существует небольшая вероятность того, что произойдет сбой системы, например устаревшая версия работающего узла, которая приведет к сбою теста.

Настройки непрерывной интеграции/метафайлы

• Плюсы: опять же меньше багажа. Такие вещи, как .travis.yml не требуются для использования, тестирования или просмотра кода.

Документы без чтения и примеры кода

• Плюсы: меньше багажа. Некоторые люди существуют в школе мысли, где, если вы не можете выразить хотя бы минимальную жизнеспособную функциональность в вашем Readme, ваш модуль слишком велик.
• Минусы: люди не могут видеть исчерпывающую документацию и примеры кода в своей файловой системе. Они должны были бы посетить хранилище (которое также требует подключения к интернету).

Github-страницы объектов

• Плюсы: Вам, конечно, не нужно засорять свои релизы файлами CNAME или местозаполнителем index.html если вы используете свой модуль, который также выполняет двойную функцию в качестве хранилища gh-pages.

bower.json и друзья

• Плюсы: если вы решите встроить свои зависимости до выпуска, вам не нужно, чтобы конечный пользователь устанавливал bower, а затем устанавливайте больше с этим. Лично я бы оставил эти вещи в упаковке. Когда я делаю npm install, я должен полагаться только на npm и никаких других внешних источников.

По сути, вы должны когда-либо использовать его, если есть что-то, что вы хотите сохранить в своем пакете npm, но не в своем репозитории npm. Это не длинный список элементов, но npm лучше встроит функциональность, чем в застревание людей с нерелевантными объектами в их пакете.

Ответ 2

Я согласен с коротком и синтаксическим ответом lante и Ответ большого ответа SamT:

• Вы не должны включать ваши тесты в свой пакет.
• В вашем пакете должны содержаться только файлы исполняемых файлов.
• Это сделает ваш пакет более простым и быстрым, чтобы быть загруженным.

Мой вклад в эти ответы:

. npmignore - это способ черного списка для выбора пакета файлов. Но более практичным способом вы можете белый список файлов, которые необходимо включить в свой пакет используя поле файлов в вашем package.json:

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

Я думаю, что это простое, будущее доказательство и лучшая семантика;)

Ответ 3

Чтобы уточнить, в любое время кто-то npm install your-library, npm загрузит все исходные файлы, которые включает репо, кроме файлов, которые вы добавляете в свой .npmignore.

Знайте, что людям, устанавливающим вашу библиотеку, потребуется только ваша библиотека, что-то еще не нужно.

Например, когда кто-то устанавливает библиотеку, возможно, что он/она не заботится о ваших файлах .travis.yml или ваших .jshintrc или даже некоторых изображениях, файлах Grunt, документации и т.д.

.npmignore может позволить вашему пакету npm иметь меньше файлов и быстрее загружаться

Ответ 4

Не включайте ваши тесты. Часто тесты примерно в 5 раз больше фактической базы кода. Пока ваши тесты на Github и т.д., Этого достаточно.

Но то, что вы обязательно должны сделать, это протестировать ваш пакет NPM в опубликованном формате. Создайте некоторые тесты дыма, которые находятся в фактической базе кода, но не являются частью набора тестов.

Вы можете прочитать о тестировании вашего пакета после его архивирования, здесь: https://github.com/ORESoftware/r2g

Как проверить результат "npm publish", не публикуя его в NPM?