Сегодня мне пришлось отлаживать очень неинформативную ошибку:
npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/Excel-export npm ERR! 404 npm ERR! 404 ‘Excel-export’ is not in the npm registry. npm ERR! 404 Your package name is not valid, because npm ERR! 404 1. name can no longer contain capital letters npm ERR! 404 It was specified as a dependency of ‘excel-export-reproduction’ npm ERR! 404 npm ERR! 404 Note that you can also install from a npm ERR! 404 tarball, folder, http url, or git url.
Я получил эту ошибку при отправке моего кода на постановку. Больше нигде не проявлялось. Шаг 1 заключался в простом откате изменений, чтобы я мог продемонстрировать некоторые другие функции своему клиенту.
Первое, что я сделал (после того, как закончил другую, более важную работу), — это поиск «Excel-export» (с учетом регистра). Поиск, который оказался… ничего. Нигде в моем исходном коде нет ссылки на пакет «Excel-export». Однако это меня не удивляет, потому что я использую пакет метеора под названием «excel-export», а пакеты метеора могут иметь зависимости от npm.
На данный момент я полагаю, что автор «nicolaslopezj:excel-export», вероятно, допустил небольшую ошибку и по ошибке написал имя пакета npm с большой буквы (со всеми задействованными платформами я думал, что подобная ошибка может легко остаться незамеченной какое-то время).
Следующим шагом является изучение пакета «nicolaslopezj: excel-export». Я снова ищу ошибочное имя пакета «Excel-export» (с учетом регистра). И снова я не нахожу… ничего. Какие бы другие ошибки ни были в пакете, nicolaslopezj тщательно взял на себя обязательство использовать заглавные буквы в имени любого пакета npm, который он использует.
На данный момент я довольно озадачен тем, как ошибка npm «не удалось загрузить пакет Excel-export» может быть вызвана пакетом npm с именем «excel-export», я имею в виду, что если вы не можете загрузить пакет, как это вызывает ошибки в вашей системе! Однако ничего не остается, кроме как исследовать пакет «excel-export» и посмотреть, что я могу найти.
Когда я ищу https://github.com/functionscope/Node-Excel-Export для Excel-export с учетом регистра, я нахожу… 1 совпадение. В example/package.json есть ссылка, фактически она находится в поле имя. Имя примера приложения (как определено в его package.json) — Excel-export.
Я все еще в замешательстве… пример приложения на самом деле не является частью пакета, который я пытаюсь использовать, и, что более важно, он ничем не «требуется»… нигде. Так почему же это влияет на мое развертывание? Либо это?
Я очень заинтересован в развертывании моей функции, и это определенно зависит от пакета excel-export, поэтому я решаю: давайте это исправим. Я добавляю оба пакета meteor и npm excel-export в свой проект (чтобы мое приложение использовало локальные версии) и удаляю каталог «example» из пакета npm. Мне нужно сделать небольшой рефакторинг пакета npm, чтобы он работал как часть моего пакета meteor, но менее чем за 10 минут у меня есть версия моего приложения, которая работает локально и не имеет npm. зависимость для «excel-экспорт».
Когда я пытаюсь развернуть свое приложение с измененным пакетом, все работает нормально. Приложение собирается и загружается на сервер, и я могу продемонстрировать свою новую функцию своим клиентам. Ура!
Но… что вызвало проблему? С какой стати пример приложения в каталоге пакета может вызвать сбой моего процесса развертывания? Решил копать дальше.
На данный момент я знаю, что проблема вызвана ошибкой в каком-то другом коде, но я не знаю, в чьем. Я решил, что лучший способ — создать репозиторий воспроизведения (мой клиент определенно не хочет, чтобы я размещал их код в общедоступной сети) и придумать несколько очень конкретных шагов, необходимых для воспроизведения проблемы. Затем я могу опубликовать репродукцию на различных форумах по отслеживанию проблем или поддержке и посмотреть, знает ли кто-нибудь, что происходит.
Когда я определяю точные шаги, необходимые для воспроизведения проблемы, я решаю, что мне действительно следует попытаться определить, является ли метеор или модуль причиной проблемы, по крайней мере, настолько, насколько я могу. Я полагаю, что лучший способ сделать это - попытаться воспроизвести проблему без модуля. Насколько я понимаю, модуль просто запускает `meteor build`, а затем загружает его на серверы модуля, поэтому я полагаю, что мне следует запустить `meteor build` и попытаться запустить его как чистое приложение node.
После того, как я создал проект, шаги для его запуска довольно просты, в основном просто запустите «npm install» внутри каталога «programs/server» и экспортируйте необходимые переменные (например, корневой URL-адрес и URL-адрес mongo), а затем запустите app с `узлом main`.
Однако, когда я пытаюсь запустить `npm install`, я получаю сообщение об ошибке (здесь я сильно сократил трассировку стека):
make: *** [Release/obj.target/fibers/src/fibers.o] Error 1
На данный момент я помню, что метеор использует (~ 0,10) другую версию узла, которую я установил (~ 5,4), поэтому я решил попробовать запустить приложение с версией узла метеора.
Найти метеорную версию узла было не так-то просто. Мало того, что версия узла метеора не хранится в особенно очевидном месте, это место изменилось где-то между 0.8 и версией метеора, которую я сейчас использую (1.1). После прочтения этой статьи и этого сообщения о переполнении стека я успешно нашел правильную версию узла здесь:
~/.meteor/packages/meteor-tool/.1.1.10.dhuz4u++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/bin/node
(Остерегайтесь разрывов строк. Вам также нужно использовать версию npm в том же каталоге. Ключевым моментом здесь было получить самую последнюю версию инструмента, для меня это была 1.1.10, которую вы можете увидеть примерно на полпути. дорожка.)
Как только у меня были правильные версии node и npm, я смог без проблем запустить свое приложение репо. До сих пор я оставлял открытой возможность того, что ошибка в метеоре могла каким-то образом задушить пакет excel-export, но на данный момент я начинаю думать, что это очень маловероятно. Вместо этого я решил сосредоточиться на инструменте модуля.
Я решил еще немного покопаться в процессе развертывания модуля. На этот раз я развертываю приложение для воспроизведения с минимальным набором пакетов («meteor create» и «meteor add nicolaslopezj:excel-export»). Я получаю ту же ошибку. Я убиваю инструмент модуля до того, как он успеет очиститься.
Теперь у меня есть каталог `.demeteorized`, который модуль действительно загружает на свой сервер. Внутри этого каталога находится файл package.json, который не генерируется метеором, и там я нахожу виновника: зависимость под названием «Excel-export» с версией «0.3.1», которая точно соответствует файлу package.json в пример приложения excel-export.
Здесь произошло то, что инструмент demeteorizer сканирует каталог сборки метеора на наличие файлов package.json и использует эти файлы для создания файла package.json для приложения метеора (я думаю, чтобы эти зависимости можно было загрузить для правильной платформы). В способе сканирования этих файлов пакетов есть ошибка, из-за которой инструмент включает пакеты, которые на самом деле не являются частью проекта, только потому, что они находятся в каталоге node_modules.
Пара выводов здесь:
- Это пример того, как система пакетов метеора превосходит другие системы пакетов, в пакете метеора вы должны конкретно указать каждый файл, который на самом деле является частью вашего пакета, и только эти файлы будут упакованы и включены в окончательную сборку проекта. .
- Это пример того, почему вы должны обновить версии своих инструментов (если это возможно), оказывается, эта ошибка уже была исправлена, простое обновление моей версии модуля устранило проблему. (Два замечания по этому поводу: 1) В последний раз, когда я обновлял свою версию модуля, это нарушило мой процесс развертывания, поэтому я в первую очередь запускал более старую версию. 2) Мне не удалось `npm update -g modulus`, и мне пришлось удалить и переустановить пакет.)
- Казалось бы, несвязанные изменения могут иметь неожиданные последствия во время развертывания.
- Если бы я подумал об отключении инструмента модуля в середине процесса и проверил каталог `.demeteorized` раньше, я, вероятно, раньше бы понял, что проблема связана с инструментом модуля, и сначала обновил бы его.
- Концепция Meteor как инструмента, который может загружать и запускать любую версию самого себя в зависимости от требований к версии вашего приложения, довольно крутая. Если бы можно было указать версию node/npm в верхней части соответствующих файлов, это было бы довольно крутой идеей.
