Чи потрібно зафіксувати файл package-lock.json, створений npm 5?

npm 5 випущено сьогодні, і одна з нових функцій включає детерміновані встановлення зі створенням package-lock.jsonфайлу.

Чи повинен цей файл зберігатись у контролі джерела?

Я припускаю, що це схоже на, yarn.lockі composer.lockобидва вони повинні зберігатися в контролі джерел.

Так, package-lock.jsonпризначено перевірити джерело управління. Якщо ви використовуєте npm 5, ви можете побачити це в командному рядку: created a lockfile as package-lock.json. You should commit this file.Відповідно npm help package-lock.json:

package-lock.jsonавтоматично генерується для будь-яких операцій, де npm модифікує або node_modulesдерево, або package.json. Він описує точне дерево, яке було сформовано таким чином, що наступні установки можуть генерувати однакові дерева, незалежно від проміжних оновлень залежності.

Цей файл призначений для введення в сховища джерел і служить різним цілям:

• Опишіть одне представлення дерева залежностей таким чином, що колеги, розгортання та безперервна інтеграція гарантовано встановлюють однакові залежності.

• Забезпечте можливість для користувачів "подорожувати часом" до попередніх станів node_modulesбез необхідності вводити сам каталог.

• Для полегшення більшої видимості змін дерев через читабельний контроль джерела відрізняється.

• І оптимізуйте процес встановлення, дозволяючи npm пропускати повторні розділення метаданих попередньо встановлених пакетів.

Однією з основних деталей package-lock.jsonє те, що вона не може бути опублікована, і вона буде ігнорована, якщо знайдеться в будь-якому іншому місці, крім пакету топлерів. Він поділяє формат з npm-shrinkwrap.json (5), який по суті є тим самим файлом, але дозволяє публікувати. Це не рекомендується, якщо не розгортати інструмент CLI або іншим чином використовувати процес публікації для виготовлення виробничих пакетів.

Якщо обидва package-lock.jsonі npm-shrinkwrap.jsonприсутні в корені пакету, package-lock.jsonбуде повністю проігноровано.

Так, це має бути зареєстровано. Я хочу припустити, що він отримує свою унікальну комісію. Ми виявляємо, що це додає багато шуму нашим розсіям.

Так, ПОТРІБНО:

1. здійснити package-lock.json.
2. використовувати npm ciзамість того,npm install щоб будувати додатки як на вашому ІМ, так і на локальній машині розвитку

Робочий npm ciпроцес вимагає існування а package-lock.json.

Великим недоліком npm installкоманди є її несподівана поведінка, що вона може вимкнути функцію package-lock.json, тоді як npm ciвикористовуються лише версії, визначені у файлі блокування, і створює помилку

• якщо package-lock.jsonі package.jsonне синхронізовано
• якщо а package-lock.jsonвідсутній

Отже, працює npm installлокально, особливо у великих командах з кількома розробниками може призвести до безлічі конфліктів package-lock.jsonі розробники вирішать повністю видалити package-lock.jsonзамість цього.

Однак є вагомий приклад використання для того, щоб можна було довіряти, що залежності проекту вирішуються повторно надійно на різних машинах.

Від package-lock.jsonви отримуєте саме це: відомий для роботи стан.

У минулому у мене були проекти без package-lock.json/ npm-shrinkwrap.json/yarn.lock файлів, файли яких не вдалося б одного дня виправити, оскільки випадкова залежність отримала невдале оновлення.

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

Якщо ви хочете додати нову залежність, ви все одно запустите npm install {dependency}. Якщо ви хочете оновити, використовувати або npm update {dependency}чи npm install ${dependendency}@{version}й здійснювати змінене package-lock.json.

Якщо оновлення не вдалося, ви можете повернутися до останнього відомого робочого package-lock.json.

Щоб процитувати НПМ документ :

Настійно рекомендується змусити згенерований замок пакета контролювати джерело: це дозволить будь-кому іншому у вашій команді, вашим розгортанням, вашій CI / постійній інтеграції та будь-кому іншому, хто працює npm, встановити у вашому джерелі пакета, щоб отримати саме таке дерево залежності що ви розвивали. Крім того, відмінні від цих змін люди читають і інформують вас про будь-які зміни, які внесли npm у ваші node_modules, тож ви можете помітити, чи були оновлені, підняті будь-які перехідні залежності тощо.

А щодо різниці між npm civsnpm install :

• Проект повинен мати існуючий пакет-lock.json або npm-shrinkwrap.json.
• Якщо залежності в блокуванні пакета не відповідають тим, що в пакет.json, npm ciвийдуть з помилкою, замість оновлення блокування пакета.
• npm ci може встановлювати лише цілі проекти за один раз: окремі залежності не можна додавати за допомогою цієї команди.
• Якщо a node_modulesвже присутній, він буде автоматично видалений перед npm ciпочатком його встановлення.
• Він ніколи не запише до package.jsonабо будь-який із пакетів-замок: установки фактично заморожені.

Примітка: аналогічну відповідь я розмістив тут

Так, найкраща практика - це заїзд (ТАК, ЗАВДАННЯ)

Я погоджуюся, що це спричинить багато шуму або конфлікту, коли побачиш різницю. Але переваги:

1. гарантувати точно таку ж версію кожного пакета . Ця частина є найважливішою при будівництві в різних середовищах у різний час. Ви можете використовувати ^1.2.3у своїх package.json, але як ви можете переконатись, що кожен раз npm installпідбиратиме однакову версію на вашому Dev-машині та на сервері збирання, особливо тих пакетів непрямої залежності? Ну, package-lock.jsonзабезпечить це. (За допомогою npm ciякого встановлює пакети на основі файлу блокування)
2. це покращує процес установки.
3. це допомагає з новою функцією аудиту npm audit fix(я думаю, що функція аудиту походить з npm версії 6).

Я не ввожу цей файл у своїх проектах. У чому справа ?

1. Це генерується
2. Це є причиною помилки цілісності коду SHA1 в gitlab з побудовами gitlab-ci.yml

Хоча це правда, що я ніколи не використовую ^ у своєму пакеті.json для libs, тому що у мене був поганий досвід з ним.

Для людей, які скаржаться на шум під час роботи git:

git diff -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'

Що я робив - це псевдонім:

alias gd="git diff --ignore-all-space --ignore-space-at-eol --ignore-space-change --ignore-blank-lines -- . ':(exclude)*package-lock.json' -- . ':(exclude)*yarn.lock'"

Щоб ігнорувати package-lock.json в diff для всього сховища (усі, хто ним користується), ви можете додати це до .gitattributes:

package-lock.json binary
yarn.lock binary

Це призведе до розбіжностей, які показують, що "Бінарні файли a / package-lock.json та b / package-lock.json відрізняються при зміні файлу блокування пакета. Крім того, деякі служби Git (зокрема GitLab, але не GitHub) також будуть виключати ці файли (не більше 10k рядків змінено!) від відмінних при перегляді в Інтернеті, коли це роблять.

Так, ви можете скопіювати цей файл. З офіційних документів npm :

package-lock.jsonавтоматично генерується для будь-яких операцій, де npmзмінюється або node_modulesдерево, абоpackage.json . Він описує точне дерево, яке було сформовано таким чином, що наступні установки можуть генерувати однакові дерева, незалежно від проміжних оновлень залежності.

Цей файл призначений для введення у сховища джерел [.]

Вимкнути пакет-lock.json у всьому світі

введіть у свій термінал наступне:

npm config set package-lock false

це справді працює для мене, як магія

Так, це стандартна практика вчинення пакета-lock.json

Основна причина здійснення пакету-lock.json полягає в тому, що всі учасники проекту знаходяться в одній версії пакету.

Плюси: -

• Якщо ви дотримуєтесь суворої версії та не дозволяєте автоматично оновлювати основні версії, щоб уберегти себе від невідповідних змін у сторонніх пакетах, що здійснюють блокування пакетів.
• Якщо ви оновлюєте певний пакет, він оновлюється в package-lock.json, і кожен, хто використовує сховище, оновлюється до тієї конкретної версії, коли приймає зміни.

Мінуси: -

• Це може зробити ваші запити на тягнення виглядати некрасиво :) '

Редагувати: - npm install не переконається, що всі в проекті є в одній версії пакета. npm ci допоможе в цьому.

Моє використання npm - це генерувати мінімізований / погіршений css / js та генерувати JavaScript, необхідний на сторінках, що обслуговуються програмою django. У моїх програмах Javascript працює на сторінці для створення анімації, інколи виконує дзвінки ajax, працює в рамках VUE та / або працює з css. Якщо пакет-lock.json має деякий переважаючий контроль над тим, що є у package.json, можливо, знадобиться одна версія цього файлу. На мій досвід, це або не впливає на те, що встановлено за допомогою npm install, або, якщо це відбувається, воно досі не впливало негативно на програми, які я розгортаю. Я не використовую mongodb та інші подібні програми, які традиційно є тонкими клієнтами.

Я видаляю package-lock.json з repo, оскільки npm install створює цей файл, а npm install є частиною процесу розгортання на кожному сервері, на якому запущено додаток. Контроль версій вузла та npm виконується вручну на кожному сервері, але я обережно, щоб вони були однаковими.

Коли npm installзапускається на сервері, він змінює package-lock.json, і якщо є зміни у файлі, який записується репо на сервері, наступне розгортання WONT дозволить витягнути нові зміни з походження. Тобто ви не можете розгорнути, тому що витяг замінить зміни, внесені до пакета-lock.json.

Ви навіть не можете перезаписати локально згенерований пакет-lock.json з тим, що знаходиться в репо (reset master hard origin), оскільки npm буде скаржитися коли-небудь, коли ви видасте команду, якщо package-lock.json не відображає те, що знаходиться в node_modules завдяки npm install, тим самим порушуючи розгортання. Тепер, якщо це вказує на те, що в node_modules було встановлено трохи інші версії, це ще раз не викликало у мене проблем.

Якщо node_modules не знаходиться у вашому репортажі (і цього не повинно бути), тоді пакет-lock.json слід ігнорувати.

Якщо я щось пропускаю, будь ласка, виправте мене в коментарях, але пункт про те, що версія взята з цього файлу, не має сенсу. У файлі package.json є номери версій, і я припускаю, що цей файл використовується для створення пакетів, коли відбувається встановлення npm, як, коли я його видаляю, npm install скаржиться так:

jason@localhost:introcart_wagtail$ rm package.json
jason@localhost:introcart_wagtail$ npm install
npm WARN saveError ENOENT: no such file or directory, open '/home/jason/webapps/introcart_devtools/introcart_wagtail/package.json'

і збірка не вдається, проте при встановленні node_modules або застосуванні npm для збирання js / css, скарга не подається, якщо я видаляю package-lock.json

jason@localhost:introcart_wagtail$ rm package-lock.json 
jason@localhost:introcart_wagtail$ npm run dev

> introcart@1.0.0 dev /home/jason/webapps/introcart_devtools/introcart_wagtail
> NODE_ENV=development webpack --progress --colors --watch --mode=development

 10% building 0/1 modules 1 active ...