Распространенные ошибки NPM, которых следует избегать каждому разработчику

Узнайте, как избежать типичных ошибок при управлении зависимостями, публикации пакетов и т. Д.

NPM - крупнейший в мире менеджер пакетов, и использовать его на практике относительно просто. Однако при добавлении пользовательских конфигураций или использовании расширенных функций многое может пойти не так.

Итак, в этой статье я рассмотрю семь распространенных ошибок, которых следует избегать при использовании 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 файлах.

Однако использование команд интерфейса командной строки не всегда гарантирует плавный процесс обновления зависимостей.

Например, если вы выполняете npm i --save package@~1.0.0, вы можете ожидать, что шаблон @version будет отражен в пакете. Но вместо этого мы можем использовать символ ^, чтобы сохранить версию с обновлением положений в package.json.

Поэтому всегда дважды проверяйте свой package.json после обновления зависимостей.

2. Блокировка зависимостей вашего пира до определенной версии патча.

Обычно peerDependencies используются, чтобы избежать дублирования установок зависимостей пакетов. И будет раздражать, если мы заблокируем зависимости одноранговых узлов определенной версией патча. Итак, давайте рассмотрим простой пример, чтобы понять основную причину этой проблемы.

{
  "name": "tea-latte",
  "peerDependencies": {
    "tea": "1.x"
  }
}

Согласно приведенному выше коду, модуль tea-latte зависит от конкретной версии (например, 1.x) пакета tea.

Но в вашем проекте могут быть другие пакеты или модули, которые зависят от последней версии пакета tea. Следовательно, блокировка пакета tea для более старой версии может вызвать непредвиденное поведение в вашем приложении.

Примечание. Если одноранговые зависимости явно не зависят от более высоких версий в дереве зависимостей, NPM версий 1, 2 и 7 установит их автоматически. Версии 3,4,5 и 6 выдадут вам предупреждающее сообщение.

3. Публикация нескольких модулей как одного пакета

Будь то библиотека пользовательского интерфейса, служебный «набор инструментов» или любая другая группа модулей, почти всегда плохая идея публиковать их все как единый пакет.

Нет причин, по которым мы должны заставлять потребителей нашего кода связывать свой проект с полным набором модулей или компонентов, когда все, что им нужно, - это его часть. Они должны выбирать, что использовать и какую версию, и им никогда не придется иметь дело с бессмысленными обновлениями.

Скорее всего, вы согласны со мной, но страшитесь мысли об управлении монорепозиторием для поддержки всех этих пакетов. На это я говорю: не бойтесь!

Экосистема JS прошла долгий путь со времен дихотомии монореп-полирепо.

Теперь нам повезло, что мы можем управлять исходным кодом и публиковать независимые компоненты из простых CRA-подобных проектов с автоматически созданными package.json, документацией и т. Д.

Чтобы узнать больше об использовании Bit для публикации нескольких пакетов, см. Здесь:

4. Случайная публикация конфиденциальных данных.

Если вы случайно публикуете модуль, содержащий конфиденциальную информацию, первое, что вы можете сделать, это отменить публикацию пакета.

Но после публикации модуля он копируется на все зеркала реестра. Отмена публикации ничего не изменит.

Белые списки - это удобный способ защитить то, что вы публикуете в реестре, и избежать случайного раскрытия конфиденциальных данных.

Все, что вам нужно сделать, это изменить package.json свойством с именемfiles. со свойством files вы можете легко указать файлы или каталоги, которые нужно опубликовать.

{
 “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”
}

Поэтому я рекомендую использовать белые списки, чтобы контролировать, какие файлы будут включены в ваш следующий пакет.

5. Предоставление обычного токена аутентификации.

Если вы используете частные модули в конвейере CI / CD, вам необходимо предоставить токен аутентификации. Однако интерфейс командной строки NPM не позволяет управлять доступом для чтения и записи при генерации этих токенов.

Вы вручную генерируете токен с помощью API общедоступного реестра и избегаете любых уязвимостей безопасности, вызванных токенами.

Приведенная ниже команда сгенерирует для вас токен с доступом только для чтения.

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 таких ошибок, которые мы совершаем, и лучшие методы их предотвращения.

Итак, я надеюсь, что с этого момента вы будете использовать их в своем проекте, и если у вас есть какие-либо предложения, поделитесь ими в разделе комментариев.

Спасибо за чтение !!!

Учить больше