Git: конфликт в package-lock.json при merge

#Что означает проблема

При объединении веток Git может записать метки конфликта в package-lock.json. Этот файл содержит полное дерево зависимостей и служебные контрольные суммы; неправильная ручная правка порой даёт формально корректный JSON, но невозможную установку. Инструкция относится к проектам npm; для yarn.lock, pnpm-lock.yaml или composer.lock нужен инструмент соответствующего менеджера.

#Как отличить причины

#Пошаговая диагностика и решение

1. Откройте проект и посмотрите, какое слияние выполняетсяВ VS Code выберите «Файл» → «Открыть папку» с корнем проекта, затем «Терминал» → «Создать терминал». Запустите git status: должны быть записи You have unmerged paths и путь package-lock.json. Проверьте, что речь о merge, а не rebase: при rebase порядок «ours/theirs» отличается. Если рабочая папка содержит важные незакоммиченные данные, сделайте копию до продолжения. Перед остальными командами выполните git --version: в ответ должна появиться установленная версия Git. Если терминал сообщает, что git не найден, проверьте установку Git и доступность команды в этом терминале; не продолжайте операции наугад.
2. Проверьте менеджер зависимостей и закреплённую версию NodeОткройте корневые файлы в левой панели VS Code: package.json, package-lock.json, возможные .nvmrc или поле packageManager. В терминале выполните node --version и npm --version. Если lock-файл отсутствует, а есть pnpm-lock.yaml, эта инструкция не подходит. Если в проекте закреплена версия npm, переключитесь на неё штатным менеджером версий Node по инструкциям команды, не устанавливайте случайно самый новый npm.
3. Согласуйте package.json, если в нём есть конфликтОткройте package.json в VS Code, нажмите на строку помеченного конфликта или выберите встроенный редактор слияния. Сравните обе версии поля dependencies, devDependencies, scripts и engines, вручную сохраните нужные зависимости обеих веток, уберите все маркеры конфликта. Для файла JSON нельзя оставлять комментарии и завершающие запятые. Если версии библиотек несовместимы, согласуйте их с владельцем проекта вместо произвольного выбора.
4. Сделайте копию lock-файла перед его пересозданиемВ проводнике файлов скопируйте package-lock.json за пределы папки проекта, например в отдельную временную папку. Это нужно, чтобы можно было сравнить точные версии. Не удаляйте существующую папку node_modules, базу данных или другие файлы только из-за конфликта: данная процедура не требует очистки.
5. Примените разрешение конфликта через npmЕсли уже исправлен package.json, попробуйте npm install --package-lock-only из корня проекта. Параметр обновляет только lock-файл, не устанавливая зависимости в node_modules; npm умеет объединять некоторые конфликты lock-файла. Если npm не смог разобрать конфликтующие маркеры, сначала получите с команды согласованный план восстановления и сохраните обе исходные версии через git show :2:package-lock.json и git show :3:package-lock.json, вместо ручного стирания половины файла.
6. Проверьте полученную структуру и устраните ошибкиПосле успешного завершения npm install --package-lock-only проверьте, что git diff -- package.json package-lock.json показывает ожидаемые изменения и в файлах нет <<<<<<<. Если npm сообщает ERESOLVE, не включайте постоянно --legacy-peer-deps и --force: сначала уточните конфликтующие версии пакетов и требуемую версию npm. Если lock-файл изменился полностью, возможно, у вас другая версия npm — вернитесь к согласованной.
7. Отметьте файлы разрешёнными и проверьте установкуКогда оба файла валидны, выполните git add package.json package-lock.json и посмотрите git status. После завершения слияния выполните в подходящем рабочем окружении npm ci; он может пересоздать node_modules, поэтому до этого сохраните локальные неповторимые данные и убедитесь, что зависимостей в нём не редактировали вручную. npm ci должен завершиться без ошибки синхронизации package.json и lock-файла, затем запустите тесты проекта.
8. Завершите слияние или отмените неудачноеЕсли git status всё ещё показывает незавершённое слияние, проверьте список файлов и создайте завершающий коммит командой git commit, когда все конфликты разрешены. Если в процессе возник риск потери чужих изменений, до завершения попробуйте git merge --abort только при обычном merge; он возвращает состояние до слияния насколько это возможно, но не заменяет сделанную копию. При rebase способ отмены другой (git rebase --abort), не путайте эти режимы.

#Команды для проверки и исправления

#Как проверить результат и что делать, если не помогло

Проверка: git status не содержит unmerged paths, оба JSON разбираются, npm ci на согласованной версии npm завершается успешно, тесты приложения проходят. Если отказ связан с несовместимыми версиями библиотек, сообщите разработчику список зависимостей из npm и не отправляйте непроверенный lock-файл.