#Как проявляется ошибка и когда применим способ
Сценарий из scripts в package.json запускается на ноутбуке, но падает в Linux-сервисе, контейнере или при автоматическом развёртывании. Это обычно различие путей, пользователя, переменных окружения и режима установки devDependencies, а не «поломка npm».
#Причины и признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Разные версии или рабочая папкаСкрипт вызывается из каталога без ожидаемого package.json либо со старым Node.js. | Локально команда успешна, на сервере ENOENT, command not found или SyntaxError. | Сопоставить cwd, PATH и версии инструментов. |
| Нет окружения сборкиСервис работает без секретов или с установленными только production-пакетами. | Зависимость упоминается в devDependencies, на сервере её нет. | Разделить стадию сборки и исполнения; правильно передать переменные. |
#Пошаговая диагностика и решение
- 1. Запишите, как именно запускается сценарийОткройте файл сценария развёртывания, конфигурацию службы или CI и найдите строку npm run ИМЯ. Зафиксируйте настоящее имя scripts и первое сообщение ошибки целиком, не публикуя пароли и переменные окружения. Если ошибка наблюдается только на сервере, тестируйте сначала в отдельном каталоге.
- 2. Сверьте Node.js, npm и расположение проектаПодключитесь к серверу под тем пользователем, который обычно собирает приложение, откройте терминал и перейдите в каталог проекта. Команды ниже только читают сведения; на Windows используйте PowerShell и pwd. Если npm pkg get выводит {} или undefined, вы открыли не тот package.json.
- Запуск без sudo от пользователя сборки; читает cwd, версии и scriptsLinux · Терминал (Bash)КомандаЗапуск без sudo от пользователя сборки; читает cwd, версии и scripts.
pwdnode --versionnpm --versionnpm pkg get scripts
- 3. Запустите отдельный скрипт вручнуюВ тестовой папке выполните ту же команду npm run ИМЯ_СКРИПТА, что запускается в CI. Смотрите первую ошибку, а не последние строки обобщённого завершения. Если вручную всё работает, разница вероятнее в пользователе службы или наборе переменных.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюЗамените имя; скрипт может выполнять произвольные команды из package.json, поэтому только доверенный проект и тестовая среда.
npm run ИМЯ_СКРИПТАКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 4. Проверьте зависимости и режим сборкиВ package.json откройте dependencies и devDependencies. Если vite, tsc или другой инструмент сборки есть только во второй секции, сборка должна выполняться в среде с devDependencies. В копии с lock-файлом выполните npm ci --include=dev. Не заставляйте production-процесс держать инструменты компиляции постоянно.
- Дополнительная команда по темеLinux · Терминал (Bash)С осторожностьюВ копии каталога: переустановит node_modules, включая зависимости разработки; может выполнять установочные скрипты.
npm ci --include=devКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
- 5. Проверьте пользователя, разрешения и переменныеДля systemd изучите unit-файл: поля User, WorkingDirectory, Environment/EnvironmentFile, ExecStart. Для CI посмотрите назначенный рабочий каталог и переменные, а для Windows-службы — учётную запись службы. Секреты не выводите в журнал; сверяйте лишь наличие и правильность безопасных значений.
- 6. Уберите зависимость от интерактивной оболочкиНе рассчитывайте на переменные, заданные только в .bashrc, и программы, доступные лишь через пользовательские менеджеры версий. Укажите в конфигурации службы абсолютный путь к интерпретатору и рабочий каталог, если это требуется; любые правки сперва проверяйте на копии файла службы.
- 7. Проверьте сборку под нужной учётной записьюПовторите запуск командой из процедуры развёртывания под тем же непривилегированным пользователем. Ожидайте код возврата 0 и созданные артефакты из scripts. Если проблема сохраняется, сравните фактическое окружение процесса с локальным и верните сохранённый сценарий.
#Проверка результата и действия при повторении
Одинаковый сценарий npm run выполняется в тестовом окружении сервера без прав администратора и создаёт ожидаемые файлы. После смены настроек перезапустите только тестовый процесс, проверьте журнал и код возврата, затем применяйте проверенные изменения на рабочем сервере.
Если на указанном шаге результат отличается, остановитесь и запишите первое полное сообщение об ошибке, версию инструментов и проверенное состояние до исправления. Не переходите к опасным действиям на действующем проекте: повторите проверку на отдельной копии, верните сохранённые файлы и только затем выбирайте следующую причину.