Распространенные ошибки NPM, которых следует избегать
1. Добавление зависимостей в package.json вручную
Содержание статьи:
Вам следует избегать обновления package.json вручную, так как это может нарушить синхронизацию между package.json и package-lock.json.
Вместо этого, вы можете использовать CLI команды, такие как npm i –save и npm i —save-dev для автоматического обновления package.json и package-lock.json. Они также предупредят вас, если есть какие-либо несовпадения версий в этих 2 файлах.
Однако использование CLI команд не всегда гарантирует что процесс обновления зависимостей пройдет без ошибок.
Например, если вы выполните npm i —save package@~1.0.0, вы можете ожидать, что версия шаблона @ будет отражена в пакете. Но вместо этого мы можем использовать символ ^ для сохранения версии в обновленном package.json. Итак, всегда перепроверяйте свой package.json после обновления зависимостей.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
2. Блокировка peer dependencies определенной версии патча.
Обычно, чтобы избежать дубликации зависимостей пакетов, используются peerDependencies. И будет досадно, если мы заблокируем зависимости определенной версией патча. Давайте рассмотрим простой пример, чтобы понять фундаментальную причину этой проблемы.
JavaScript { “name”: “tea-latte”, “peerDependencies”: { “tea”: “1.x” } }
| 123456 | { “name”: “tea-latte”, “peerDependencies”: { “tea”: “1.x” }} |
Согласно приведенному выше коду, модуль tea-latte зависит от конкретной версии (например, 1.x) пакета tea. Но в вашем проекте могут быть другие пакеты или модули, которые зависят от последней версии пакета tea. Следовательно, блокировка пакета tea для более старой версии может вызвать неожиданное поведение в вашем приложении.
Примечание. Если peer dependencies явно не зависят от более высоких версий в дереве зависимостей, NPM версий 1, 2 и 7 установит их автоматически. Версии 3,4,5 и 6 выдадут вам предупреждающее сообщение.
3. Публикация нескольких модулей как одного пакета.
Будь то библиотека пользовательского интерфейса, служебный «набор инструментов» или любая другая группа модулей, почти всегда публиковать их все как единый пакет — плохая идея.
Нет причин, по которым мы должны заставлять потребителей нашего кода связывать свой проект с полным набором модулей или компонентов, когда все, что им нужно, — это его часть. Они должны выбирать, что использовать и какую версию, и им никогда не придется иметь дело с бессмысленными обновлениями.
Скорее всего, вы согласитесь со мной, но боитесь мысли об управлении монорепозиторием для поддержки всех этих пакетов. Но я скажу вам: не бойтесь!
Экосистема JS прошла долгий путь со времен разветвления монорепозитория и полирепозитория. Теперь, мы можем управлять исходным кодом и публиковать независимые компоненты из простых проектов, подобных CRA, с автоматически созданной package.json документацией и т.д.
4. Случайная публикация конфиденциальных данных.
Если вы случайно опубликуете модуль, содержащий конфиденциальную информацию, первое, что вы можете сделать, это отменить публикацию пакета.
Но после публикации модуля он копируется на все зеркала реестра. Отмена публикации ничего не изменит. Whitelists — это удобный способ защитить то, что вы публикуете в реестре, и избежать случайного раскрытия конфиденциальных данных.
Все, что вам нужно сделать, это изменить свойство files в package.json. С помощью этого свойства вы можете легко указать файлы или каталоги, которые нужно опубликовать.
JavaScript { “name”: “my-package”, “version”: “1.0.0”, “description”: “my-package”, “scripts”: { “test”: “echo “Error: no test specified” && exit 1″ }, “files”: [ “dist/” ], “keywords”: [], “author”: “bhagya-withana” }
| 12345678910111213 | { “name”: “my-package”, “version”: “1.0.0”, “description”: “my-package”, “scripts”: { “test”: “echo “Error: no test specified” && exit 1″ }, “files”: [ “dist/” ], “keywords”: [], “author”: “bhagya-withana”} |
Поэтому я рекомендую использовать whitelists, чтобы контролировать, какие файлы будут включены в ваш следующий пакет.
5. Предоставление обычного токена аутентификации.
Если вы используете приватные модули в конвейере CI / CD, вам необходимо предоставить токен аутентификации. Однако NPM CLI не позволяет контролировать доступ для чтения и записи при генерации этих токенов.
Вы вручную генерируете токен с помощью общедоступного API и избегаете любых уязвимостей безопасности, вызванных токенами.
JavaScript. Быстрый старт
Изучите основы JavaScript на практическом примере по созданию веб-приложения
Приведенная ниже команда сгенерирует для вас токен с доступом только для чтения.
JavaScript curl -u [USERNAME]:[PASSWORD] https://registry.npmjs.org/-/npm/v1/tokens -X POST -H ‘content-type: application/json’ -d ‘{“password”:”[USERNAME]”, “readonly”: “true”}’
| 123 | curl -u [USERNAME]:[PASSWORD] https://registry.npmjs.org/-/npm/v1/tokens -X POST -H ‘content-type: application/json’ -d ‘{“password”:”[USERNAME]”, “readonly”: “true”}’ |
Кроме того, вы можете просматривать, добавлять и удалять токены, созданные вами на веб-сайте NPM.
6. Обновление ради апгрейда.
Хорошая практика — поддерживать последние версии. Однако вам не следует обновлять свои пакеты только потому, что есть новая версия. Давайте выясним почему. Для этого есть несколько причин:
В последних версиях могут быть ошибки.
Обновление версий без надлежащего изучения может вызвать неожиданное поведение в вашем приложении.
Новые функции могут оказаться бесполезными для вашего проекта.
Необходимо учитывать зависимости между другими пакетами.
Итак, вам необходимо оценить изменения и совместимость нового обновления, прежде чем обновлять зависимости библиотек вашего проекта.
7. Удаление package-lock.json.
Удаление файла package-lock.json для решения проблем с NPM стало обычной практикой среди разработчиков.
Однако этого следует избегать, поскольку файл package-lock.json отслеживает точную версию каждого установленного пакета. Например, если вы запустите npm update, обновленные версии зависимостей будут отражены в файле package-lock.json.
Итак, вместо удаления файла package-lock.json вы можете попробовать следующие варианты:
Решайте конфликты в package.json.
Уберите package-lock.json из основной ветки.
Запустите снова npm install.
Заключение
NPM является неотъемлемой частью любого проекта на основе JavaScript и помогает разработчикам эффективно устанавливать пакеты и управлять ими.
Но мы делаем много ошибок при использовании NPM, и некоторые из них могут вызвать серьезные проблемы. В этой статье я рассмотрел 7 таких ошибок, которые мы можем допустить, и лучшие методы их предотвращения. Я надеюсь, что с этого момента вы будете использовать NPM в своем проекте. Спасибо за внимание!!!
Автор: Bhagya Vithana
Источник: webformyself.com