Чи повинен я .npmignore мої тести?

Що саме я повинен вкласти .npmignore?

Тести? Такі речі , як .travis.yml, .jshintrc? Все, що не потрібно під час запуску модуля (крім readme)?

Я не можу знайти жодних вказівок щодо цього.

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

Існує не так багато офіційних відомостей про те, що завжди повинно бути там, тому що це в основному підмножина .gitignore, але з того, що я збираю, використовуючи node протягом 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 скоріше вбудував би функціонал, аніж люди застрягли у своєму пакеті з нерелевантними об'єктами.

Я згоден з коротким і відповіддю Lante синтетичного в і великому відповіді Samt в :

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

Мій внесок у ці відповіді:

.npmignore - спосіб чорного списку для вибору файлу пакета. Але більш практичним чином ви можете додати в білий список файли, які потрібно включити у свій пакет, за допомогою поля файлів у файлі 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 публікації`, фактично не публікуючи в NPM?