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

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

Официально не так много информации о том, что всегда должно быть там, потому что это в основном подмножество .gitignore, но из того, что я понял из использования узла в течение 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 скорее встроит функциональность, чем заставит людей зацикливаться на ненужных объектах в своем пакете.

Я согласен с кратким и синтетическим ответом Ланте и Большой ответ SamT:

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

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

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

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