требования к тестированию для опубликованных пакетов npm [duplicate]
using(WebClient client = new WebClient()) {
string s = client.DownloadString(url);
}
4 ответа
Как вы, вероятно, обнаружили, что NPM не указывает конкретно, что должно туда идти, скорее, у них есть список проигнорированных по умолчанию файлов . Многие люди даже не используют его, поскольку все в вашем .gitignore игнорируются в npm по умолчанию, если .npmignore не существует. Кроме того, многие файлы уже игнорируются по умолчанию, независимо от настроек, и некоторые файлы всегда исключаются из игнорирования, как указано в приведенной выше ссылке.
Не так много официальных о том, что всегда должно быть там, потому что это в основном подмножество .gitignore, но из того, что я собираю с использованием узла в течение 5-ти лет, вот что я придумал.
Примечание: По production I означает любое время, когда ваш модуль используется кем-то, а не разрабатываться на самом модуле.
Предварительно скомпилированные скомпилированные источники
Плюсы: если вы используете язык, который перекрестно компилируется в JavaScript, вы можете предварительно скомпилировать перед выпуском и не включать файлы .coffee в свой пакет, но продолжать отслеживать их в своем репозитории git.
Остатки файла сборки
Плюсы : Люди, использующие такие вещи, как node-gyp, могут иметь объектные файлы, которые генерируются во время сборки, которые никогда не должны входить в пакет. Минусы: в любом случае это всегда должно идти в .gitignore. Вы должны поместить эти вещи внутрь, если вы используете файл .npmignore, поскольку он переопределяет .gitignore с точки зрения npm.
Тесты
Плюсы: меньше багажа в вашем производственный код. Минусы: вы не можете запускать тесты в живых средах с небольшим шансом, возникает системная ошибка, например, устаревшая версия узла, которая приводит к сбою теста.
Настройки постоянной интеграции / Мета-файлы
Плюсы: опять же, меньше багажа. Такие вещи, как .travis.yml, не требуются для использования, тестирования или просмотра кода.
Документы без кода и примеры кода
Плюсы: меньше багажа. Некоторые люди существуют в школе мысли, где, если вы не можете выразить хотя бы минимальную жизнеспособную функциональность в вашем Readme, ваш модуль слишком велик. Минусы: люди не могут видеть исчерпывающие документы и примеры кода в своей собственной файловой системе.
Объекты Github-pages
Плюсы: вам, конечно, не нужно мутировать ваши релизы с помощью CNAME файлы или placeholder index.html s, если вы используете ваш модуль, используется как функция gh-pages.
bower.json и friends
Плюсы: Если вы решите создайте свои зависимости до выпуска, вам не нужен конечный пользователь для установки bower, а затем установите с ним больше вещей. Я бы лично сохранил этот материал в пакете. Когда я делаю npm install, я должен полагаться только на npm и никаких других внешних источников.
В принципе, вы должны когда-либо использовать его, если есть что-то, что вы хотите избежать из числа npm но не из вашего репозитория npm. Это не длинный список элементов, но npm скорее построит функциональность, чем люди, застрявшие с нерелевантными объектами в своем пакете.
-
1– inf3rno 19 August 2016 в 00:28
-
2– SamT 19 August 2016 в 03:59
Не включайте ваши тесты. Часто тесты похожи на 5x размер фактической кодовой базы. Пока ваши тесты Github и т. Д., Это достаточно хорошо.
Но вам абсолютно необходимо проверить свой пакет NPM в его опубликованном формате . Создайте некоторые тесты дыма, которые находятся в реальной базе кода, но не являются частью набора тестов.
Вы можете прочитать о тестировании своего пакета после его депонирования, здесь: https://github.com / ORESoftware / r2g
Как проверить результат npm publish, без фактического опубликования в NPM?
Я согласен с коротким и синтаксическим ответом lante и Большим ответом SamT :
- Вы не должны включать ваши тесты в свой пакет.
- Ваш пакет должен содержать только файлы времени исполнения.
- Это сделает ваш пакет более простым и быстрым для загрузки.
Мой вклад в эти ответы:
.npmignore - способ черного списка для выбора пакета файлов. Но более практичным способом вы можете использовать белые списки, которые необходимо добавить в свой пакет , используя поле файлов в вашем пакете. Json:
{
"files": [
"lib/",
"index.js"
]
}
Я думаю, что это проще, будущее доказательство и лучшая семантика;)
-
1– Connor 17 July 2016 в 13:17
-
2– Brady 28 July 2016 в 16:04
-
3– Ben George 3 May 2017 в 05:45
-
4– adelriosantiago 6 December 2017 в 02:40
-
5– Nicolás Fantone 25 January 2018 в 13:44
Чтобы уточнить, в любое время кто-то npm install your-library, npm загрузит все исходные файлы, которые включает репо, кроме файлов, которые вы добавляете в свой .npmignore.
Знайте, что люди, устанавливающие вашу библиотеку, будут нужно просто запустить вашу библиотеку, ничего другого не потребуется.
Например, когда кто-то устанавливает библиотеку, возможно, что он / она не заботится о ваших .travis.yml или ваших файлах .jshintrc , или даже некоторые изображения, файлы Grunt, документацию и т. д.
.npmignore может позволить вашему пакету npm иметь меньше файлов и быстрее загружаться
-
1– Mark Stosberg 22 June 2018 в 19:29