Должен ли я игнорировать свои тесты .npm?

Что именно я должен вставить .npmignore?

Тесты? Такие вещи , как .travis.yml, .jshintrc? Что-нибудь, что не нужно при запуске модуля (кроме readme)?

Я не могу найти никаких указаний по этому поводу.

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

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

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

Предрелизные кросс-скомпилированные исходники

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

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

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

Тесты

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

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

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

Документы и примеры кода без использования readme

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

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

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

bower.json и друзья

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

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

Я согласен с коротким и ответом Lante синтетического в и большом ответе Samt в :

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

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

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

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

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

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

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

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

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

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

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

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

Как проверить результат npm publish без фактической публикации в NPM?