npm собирает нативный модуль не под ту версию Node.js: сверяем runtime и заголовки. Пошаговый разбор: в одной shell вывести пути node and npm версии process.execPath and process.versions.modules, проверить менеджер версий и заголовки node-gyp, затем выполнить npm rebuild только для проблемной зависимости в чистом проекте; остановиться до удаления…
19. Зафиксируйте границы симптома
Исходная боль сформулирована узко: node сообщает ожидаемую версию но нативная зависимость собирается с несовместимым ABI, и разработчик удаляет все версии Node или package lock не проверив какой executable запустил npm и для какой версии скачаны headers. Нужный ответ также ограничен конкретным намерением: почему npm или node-gyp компилирует native addon как будто используется другая версия Node js и как сверить executable PATH npm execPath headers ABI и кэш до глобальной переустановки. Сначала запишите наблюдаемый симптом своими словами, время, версию затронутого компонента и один ожидаемый результат. Не переносите в заметки имена, адреса, токены, полные журналы или приватные ссылки. Свежая публичная карточка от 2026-08-27 подтверждает существование вопроса, но не доказывает его причину, массовость или популярность.
19. Проведите один обратимый контроль
Безопасная последовательность для этого случая: в одной shell вывести пути node and npm версии process.execPath and process.versions.modules, проверить менеджер версий и заголовки node-gyp, затем выполнить npm rebuild только для проблемной зависимости в чистом проекте; остановиться до удаления lockfile если mismatch уже виден в PATH or ABI. Меняйте один фактор за раз и перед действием сохраните исходное состояние, чтобы сравнение не смешивало несколько причин. Контроль должен повторять тот же вход, тот же маршрут и тот же ожидаемый результат. Успех фиксируется только когда целевой симптом меняется предсказуемо после одного обратимого шага. Практическая матрица именно для этой темы: матрица shell PATH × npm launcher × process.execPath × module ABI × header cache отделяет неверный runtime от stale native build; минимальный addon and npm rebuild дают обратимый контроль.
19. Сверьте вывод с первичными источниками
Доказательная граница собрана из первичных материалов. npm официально описывает rebuild как повторный запуск install lifecycle scripts и пересборку C++ add-ons после смены версии Node. Официальный репозиторий node-gyp описывает выбор Python, toolchain, target и dist-url для заголовков Node или стороннего runtime. Эти документы подтверждают только описанные в них механизмы и условия: они не позволяют автоматически назначить виновный компонент по одному совпадающему симптому. Если наблюдение расходится с документацией, вернитесь к исходному состоянию, проверьте точную версию продукта и не расширяйте изменение на другие устройства, учётные записи или окружения.
19. Остановитесь и соберите безопасный пакет
Стоп-линия наступает, если контроль не воспроизводится, появляется риск потери данных или доступа, требуется необратимый сброс либо результат зависит сразу от нескольких переменных. Для поддержки подготовьте минимальный обезличенный пакет: идентификатор сценария t18-npm-native-addon-wrong-node, версии компонентов, время проверки, ожидаемый и фактический результат, один безопасный фрагмент ошибки и перечень уже возвращённых настроек. Не прикладывайте секреты, персональные данные или полные конфигурации. Уникальная ценность такого пакета состоит в следующем: В каталоге нет intent о цепочке npm launcher, module ABI и headers; общие статьи о Node environment и package managers не дают эту матрицу native build.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 27 августа 2026 года по обезличенному публичному сигналу и прямым первичным источникам; персональные данные и частные обстоятельства не использовались.
Источники и проверка
- docs.npmjs.com: первичный материал 1 проверено 2026-08-27
- github.com: первичный материал 2 проверено 2026-08-27
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.