WebStorm - Как найти источник проблемы внутри пакета npm? (узел: 36378) [DEP0005] Предупреждение об устаревании - PullRequest
Новая
       9

WebStorm - Как найти источник проблемы внутри пакета npm? (узел: 36378) [DEP0005] Предупреждение об устаревании

0 голосов
/ 08 ноября 2018

Я начал получать эту ошибку в последние 6 месяцев, вероятно, из-за обновления до node.js.

(узел: 36378) [DEP0005] Предупреждение об устаревании: Буфер () устарел из-за к вопросам безопасности и юзабилити. Пожалуйста, используйте Buffer.alloc (), Вместо этого используются методы Buffer.allocUnsafe () или Buffer.from ().

Я определил конкретный пакет, который вызывает это предупреждение: https://github.com/irhc/js-logging

Больше не поддерживается, поэтому мне нужно покопаться и найти источник этой проблемы. Однако моя IDE (WebStorm) не показывает никаких строк кода. Я также искал исходный код и не смог найти Buffer(), используемый где-либо. Как я могу найти источник этой проблемы?

Кстати, я также использую fs в том же файле, который на самом деле содержит Buffer(), но комментирование зависимости и связанных функций не избавило от предупреждения.

Редактировать: Благодаря предложениям @ ix3 я уменьшил масштаб проблемы

  • Этого не происходит при работе на сервере узла
  • Этого не происходит при запуске теста мокко с терминала https://prnt.sc/lh012c
  • Это происходит при запуске тестов мокко из Webstorm: https://prnt.sc/lh01ac

Так что проблема во взаимодействии Webstorm + Mocha + Node + js-logging. Каждый из них работает совершенно один, но я получаю эту ошибку, когда они вместе.

1 Ответ

0 голосов
/ 08 ноября 2018

Тот факт, что js-logging больше не поддерживается, делает разумным первое место для поиска. Однако, если он не вызывает new Buffer (и ни одна из его зависимостей), то это предупреждение должно вызывать что-то еще. Как вы "определили" проблему с этим пакетом?

Возможно, вы захотите попробовать запустить вашу программу с подключенным отладчиком (например, встроенным в Chrome). Вы можете сделать это, следуя инструкциям , которые Пол Айриш объясняет здесь . Также обратите внимание, что Chrome 70 теперь предлагает ndb.

Вы также можете попытаться "очистить" все дерево исходных текстов (включая node_modules) для "нового буфера". Есть несколько способов сделать это, и они зависят от операционной системы. Например, в системе POSIX, такой как Linux, вы обычно можете сделать что-то вроде grep -drecurse "new Buffer" . из корневой папки вашего проекта, чтобы найти все вхождения этой строки во всех файлах в этом дереве.

Наконец, стоит повторить, что указанное вами сообщение не является ошибкой , а только предупреждением . Следовательно, это не вызывает никакого другого поведения. Другими словами, исправление этого только заставит сообщение исчезнуть; это существенно не изменит поведение вашей программы. Конечно, вы все равно должны стремиться решить эту проблему, поскольку предупреждение говорит о том, что в будущей версии узла код, который вы сейчас имеете, перестанет работать.

Редактировать : При просмотре видео без аудио, которое вы поделились, создается впечатление, что вы делаете все, о чем ваш вопрос не упоминал, например,

  • Вы пишете на TypeScript (что происходит, когда вы используете простой JavaScript?)
  • Вы запускаете тесты только из среды IDE (что происходит, когда вы запускаете их из командной строки?)

Вполне возможно, что вы используете старую версию ts-node, в которой использовался конструктор Buffer до мая 2018 года .

В сторону: Для отслеживания изменения зависимостей (особенно зависимостей зависимостей ....) я настоятельно рекомендую использовать yarn или как минимум package-lock.json В противном случае вполне возможно, что ваше приложение будет скомпоновано и работать в один день, а не в следующий, из-за изменений в апстриме.

...