Как обновить все пакеты npm package json

npm-update

Эта команда обновит все перечисленные пакеты до последней версии (указанной tag config), с учетом ограничений semver как вашего пакета, так и его зависимостей (если они также требуют того же package).).

Он также установит недостающие пакеты.

Если указан флаг -g , эта команда обновит глобально установленные пакеты.

Если имя пакета не указано, все пакеты в указанном расположении (глобальном или локальном) будут обновлены.

Обратите внимание, что по умолчанию npm update не будет обновлять значения semver прямых зависимостей в вашем проекте package.json , если вы хотите также обновить значения в package.json , вы можете запустить: npm update —save (или добавить параметр save=true в configuration file , чтобы сделать behavior). по умолчанию

Example

Для приведенных ниже примеров предположим, что текущий пакет — app , и он зависит от зависимостей, dep1 ( dep2 , .. etc.).. Опубликованные версии dep1 :

 "dist-tags":  "latest": "1.2.2" >, "versions": [ "1.2.2", "1.2.1", "1.2.0", "1.1.2", "1.1.1", "1.0.0", "0.4.1", "0.4.0", "0.2.0" ] >

Caret Dependencies

Если package.json app содержит:

"dependencies":  "dep1": "^1.1.1" >

Затем npm update установит [email protected] , потому что 1.2.2 — это latest , а 1.2.2 удовлетворяет требованиям ^1.1.1 .

Tilde Dependencies

Однако, если package.json app содержит:

"dependencies":  "dep1": "~1.1.1" >

В этом случае при запуске npm update будет установлен [email protected] . Несмотря на то, что тег latest указывает на 1.2.2 , эта версия не соответствует ~1.1.1 , который эквивалентен >=1.1.1

Каретные зависимости ниже 1.0.0

Предположим, app имеет зависимость от версии ниже 1.0.0 , например:

"dependencies":  "dep1": "^0.2.0" >

npm update установит [email protected] , потому что нет других версий, удовлетворяющих ^0.2.0 .

Если бы зависимость была от ^0.4.0 :

"dependencies":  "dep1": "^0.4.0" >

Затем npm update установит [email protected] , потому что это версия с наивысшей сортировкой, которая удовлетворяет ^0.4.0 ( >= 0.4.0

Subdependencies

Предположим, ваше приложение теперь также зависит от dep2 .

 "name": "my-app", "dependencies":  "dep1": "^1.0.0", "dep2": "1.0.0" > >

и сам dep2 зависит от этого ограниченного диапазона dep1

 "name": "dep2", "dependencies":  "dep1": "~1.1.1" > >

Затем npm update установит [email protected] , потому что это самая высокая версия, которую допускает dep2 . npm будет отдавать предпочтение одной версии dep1 в вашем дереве, а не двум, если эта единственная версия может удовлетворить несколько требований нескольких зависимостей в вашем дереве. В этом случае, если вам действительно нужно, чтобы ваш пакет использовал более новую версию, вам нужно будет использовать npm install .

Обновление пакетов Globally-Installed

npm update -g применит действие update к каждому глобально установленному пакету outdated , т. е. имеет версию, отличную от wanted .

Примечание. Глобально установленные пакеты обрабатываются так, как если бы они были установлены с указанным диапазоном символов вставки. Поэтому, если вам требуется обновление до latest , вам может потребоваться запустить npm install -g [. ] .

NOTE: Если пакет был обновлен до более новой версии, чем latest , его версия будет понижена.

Configuration

save

• По умолчанию: true , если только не используется npm update , где по умолчанию используется false .
• Type: Boolean

Сохраните установленные пакеты в файл package.json в качестве зависимостей.

При использовании с командой npm rm удаляет зависимость от package.json .

Также предотвратит запись в package-lock.json , если установлено значение false .

global

• Default: false
• Type: Boolean

Работает в «глобальном» режиме, поэтому пакеты устанавливаются в папку prefix вместо текущего рабочего каталога. Подробнее о различиях в поведении см. в folders .

• пакеты устанавливаются в папку /lib/node_modules , а не в текущий рабочий каталог.
• bin файлы связаны с /bin
• справочные страницы связаны с /share/man

global-style

• Default: false
• Type: Boolean

Заставляет npm установить пакет в вашу локальную папку node_modules с тем же макетом, который он использует для глобальной папки node_modules . Только ваши прямые зависимости будут отображаться в node_modules , и все, от чего они зависят, будет сведено в их папки node_modules . Это, очевидно, устранит некоторую дедупликацию. При использовании с legacy-bundling предпочтение отдается legacy-bundling .

legacy-bundling

• Default: false
• Type: Boolean

Заставляет npm установить пакет таким образом, чтобы версии npm до 1.4,, такие как включенная в узел 0.8,, могли установить пакет. Это устраняет все автоматические дедупликации. При использовании с global-style этот вариант будет предпочтительным.

omit

• По умолчанию: «dev», если для переменной среды NODE_ENV установлено значение «production», в противном случае пусто.
• Тип: «dev», «необязательный» или «одноранговый» (можно указать несколько раз)

Типы зависимостей, которые следует исключить из дерева установки на диске.

Обратите внимание, что эти зависимости по-прежнему разрешаются и добавляются в файл package-lock.json или npm-shrinkwrap.json . Они просто физически не установлены на диск.

Если тип упаковки присутствует в обоих списках —include и —omit , он будет включен.

Если результирующий список исключений включает ‘dev’ , то переменной среды NODE_ENV будет присвоено значение ‘production’ для всех сценариев жизненного цикла.

strict-peer-deps

• Default: false
• Type: Boolean

Если установлено значение true , а —legacy-peer-deps не задано, то любой конфликтующий peerDependencies будет рассматриваться как сбой установки, даже если npm сможет разумно угадать соответствующее разрешение на основе неравноправных зависимостей.

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

Когда такое переопределение выполняется, выводится предупреждение, объясняющее конфликт и задействованные пакеты. Если установлен —strict-peer-deps , это предупреждение считается ошибкой.

package-lock

• Default: true
• Type: Boolean

Если установлено значение false, то при установке игнорируются файлы package-lock.json . Это также предотвратит запись package-lock.json , если save — это true.

Эта конфигурация не влияет на npm ci .

foreground-scripts

• Default: false
• Type: Boolean

Запустите все сценарии сборки (т. е. preinstall , install и postinstall ) для установленных пакетов в процессе переднего плана, разделяя стандартный ввод, вывод и ошибки с основным процессом npm.

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

ignore-scripts

• Default: false
• Type: Boolean

Если true, npm не запускает сценарии, указанные в файлах package.json.

Обратите внимание, что команды, явно предназначенные для запуска определенного сценария, такие как npm start , npm stop , npm restart , npm test и npm run-script , по-прежнему будут запускать свой предполагаемый сценарий, если установлен ignore-scripts , но они не будут запускать какие-либо пре- или пост-скрипты.

audit

• Default: true
• Type: Boolean

Когда «true» отправляет отчеты об аудите вместе с текущей командой npm в реестр по умолчанию и во все реестры, настроенные для областей. См. документацию для npm audit для получения подробной информации о том, что передается.

bin-links

• Default: true
• Type: Boolean

Указывает npm создавать символические ссылки (или прокладки .cmd в Windows) для исполняемых файлов пакетов.

Установите false, чтобы этого не делать. Это можно использовать, чтобы обойти тот факт, что некоторые файловые системы не поддерживают символические ссылки, даже в якобы системах Unix.

fund

• Default: true
• Type: Boolean

Когда «true» отображает сообщение в конце каждого npm install , подтверждающее количество зависимостей, ищущих финансирование. Подробности см. в npm fund .

dry-run

• Default: false
• Type: Boolean

Указывает, что вы не хотите, чтобы npm вносил какие-либо изменения и что он должен сообщать только о том, что он сделал бы. Это можно передать любой из команд, которые изменяют вашу локальную установку, например, install , update , dedupe , uninstall , а также pack и publish .

Примечание. Это NOT поддерживается другими командами, связанными с сетью, например, dist-tags , owner и т. д.

workspace

• Default:
• Тип: Строка (можно указать несколько раз)

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

Допустимые значения для конфигурации workspace :

• Workspace names
• Путь к каталогу рабочей области
• Путь к каталогу родительской рабочей области (приведет к выбору всех рабочих областей в этой папке)

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

Это значение не экспортируется в среду для дочерних процессов.

workspaces

• Default: null
• Тип: null или Boolean

Установите значение true, чтобы выполнить команду в контексте всех настроенных рабочих областей.

Явная установка значения false приведет к тому, что такие команды, как install , будут полностью игнорировать рабочие области. Если не указано явно:

• Команды, работающие с деревом node_modules (установить, обновить, etc.), свяжут рабочие пространства с папкой node_modules . — Команды, выполняющие другие действия (test, exec, publish, etc.), будут работать с корневым проектом, если в конфигурации workspace не указано одно или несколько рабочих пространств.

Это значение не экспортируется в среду для дочерних процессов.

include-workspace-root

• Default: false
• Type: Boolean

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

Когда false, указание отдельных рабочих областей с помощью конфигурации workspace или всех рабочих областей с помощью флага workspaces приведет к тому, что npm будет работать только с указанными рабочими областями, а не с корневым проектом.

Это значение не экспортируется в среду для дочерних процессов.

install-links

• Default: false
• Type: Boolean

Когда установлен файл: зависимости протокола, которые существуют за пределами корня проекта, будут упакованы и установлены как обычные зависимости вместо создания символической ссылки. Этот параметр не влияет на рабочие пространства.

Руководство разработчика по обновлению пакетов npm

Самый простой способ обновить пакеты npm — установить npm-check-updates , запустить npx ncu , а затем npx ncu -u обновить package.json, за которым следует npm install для обновления пакетов в package.lock и node_modules.

Ванильный подход к npm

npm поставляется с готовыми инструментами для обновления ваших пакетов.

При запуске npm outdated вы можете получить список пакетов с доступными обновлениями:

Мы можем обновить отдельные пакеты, запустив npm update .

Давайте попробуем это для последнего пакета в списке:

npm update sass 

Войти в полноэкранный режим Выйти из полноэкранного режима. Теперь, если мы снова запустим npm outdated , мы сможем (как видно на изображении ниже), что пакет действительно был обновлен. Следует отметить, что хотя package.lock был обновлен, package.json остается нетронутым.

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

Обновления с помощью npm-check-updates

Еще один вариант, который я считаю несколько более удобным, особенно для проектов с меньшим риском, — это использование пакета npm-check-updates .

Чтобы установить его, просто запустите:

npm install -g npm-check-updates 

Войти в полноэкранный режим Выйти из полноэкранного режима.

После установки мы можем проверить наличие обновлений, запустив:

npx ncu 

Войти в полноэкранный режим Выйти из полноэкранного режима.

Подобно npm old , это дает нам список всех доступных обновлений:

Чтобы обновить один единственный пакет, мы можем запустить:

npx ncu -uf sass 

Войти в полноэкранный режим Выйти из полноэкранного режима

npm install 

Войти в полноэкранный режим Выйти из полноэкранного режима.

Теперь, если мы снова запустим npx ncu , мы увидим, что пакет sass был обновлен:

Что хорошо в пакете npm-check-updates, так это то, что мы также можем обновить все пакеты, если захотим, выполнив:

npx ncu -u 

Войти в полноэкранный режим Выйти из полноэкранного режима, а затем снова:

npm install 

Войти в полноэкранный режим Выйти из полноэкранного режима.

Теперь, если мы снова запустим npx ncu , мы получим:

Теперь и package.json , и package.lock были обновлены, так что стало понятнее, какие версии пакетов у нас есть, без необходимости заглядывать в package. заблокировать файл.

Заключение

Если вы хотите легко обновить все свои пакеты, вы можете использовать пакет npm npm-check-updates с командами, показанными выше, в противном случае вы также можете использовать встроенные команды npm npm устарел и обновление npm .

Ссылки

• https://www.npmjs.com/package/npm-check-updates
• https://docs.npmjs.com/cli/v7/commands

4 безопасных шага для обновления пакетов NPM [Шпаргалка]

Вы когда-нибудь пытались обновить пакет npm, а затем поняли, что он ломает все другие пакеты в вашем проекте Javascript?

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

В этом блоге я покажу вам, как обновить пакеты npm, не нарушая ваш проект, выполнив 4 простых шага:

1. Understand npm package versioning
2. Audit installed npm packages
3. Update only one npm package at time
4. Test your code after updating npm packages

пакетов

npm Управление версиями является важной частью npm и как безопасно использовать обновления при разработке веб-приложений.

Большинство пакетов npm соответствуют рекомендациям по семантическому управлению версиями.

Семантическое управление версиями означает, что разработчики должны составить версию пакета из трех чисел, разделенных точками (например, «0.12.31»).

МАЙОР. НЕСОВЕРШЕННОЛЕТНИЙ. Формат

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

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

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

Что означают каретка (^) и тильда (~)?

В package.json версия может иметь ^ спереди (например ^0.12.31 , ), что означает, что последняя незначительная версия может быть безопасно установлена.

Тильда (~) спереди (например, ) означает, ~0.12.31 что последняя версия патча безопасна для установки.

пакет.json
— это файл, который отслеживает все пакеты, необходимые приложению для правильной работы, а также параметры его поведения при работе на разных платформах и средах.

Шаг 2: Аудит установленных пакетов npm Перед обновлением пакетов

npm выясните, есть ли у вас веская причина.

Лучше придерживаться версии пакета, которая работает. Таким образом, у вас не будет риска того, что что-то сломается.

Основными причинами обновления пакетов npm являются:

• Последняя версия пакета, имеющая функцию, которую мы хотим
• Исправлены ошибки в последней версии пакета npm
• Обновленные зависимости для другого используемого пакета
• Уязвимость системы безопасности в пакете npm
• Обновление среды, в которой выполняется проект, несовместимо с текущей версией пакета npm

Пара команд npm, которые помогут вам провести аудит пакетов перед обновлением:

• npm list —depth 0 Список всех пакетов на верхнем уровне
• npm аудит Проверяет наличие уязвимостей системы безопасности или устаревших версий
• npm устаревший Список, отчет о версиях пакетов в сравнении с версиями, указанными в package.json файле

npm list —depth 0

npm list —depth 0 lists all installed npm packages, but only at the top level.

Листинг пакетов на верхнем уровне достаточен большую часть времени. Зависимости верхнего уровня обычно заботятся о своих внутренних зависимостях.

npm аудит

npm аудит will run a security vulnerability check against your project and report any found issues. It is not perfect, but it helps to find potential problems if you are using npm packages that have security vulnerabilities. It’s not perfect because not all vulnerabilities are reported to npm.

npm устаревший

npm устаревший will report any out-of-date packages in your project.

Отображает текущую, желаемую и последнюю версии по сравнению с версиями, указанными в файле package.json.

• Текущая: текущая установленная версия.
• Требуется: максимальная версия пакета, разрешенная диапазоном версий в файле package.json.
• Последняя: версия пакета помечена как «последняя» в реестре npm.

Note: npm устаревший command only shows the direct dependencies of the root project. But if you want to see other dependencies also, then use «—all.»

Проверьте наличие критических изменений перед обновлением

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

Перед внесением критических изменений разработчики пакетов часто добавляют сообщения «Breaking Changes» в выходные данные консоли. Это означает, что модуль будет меняться в будущих версиях, и разработчики должны следить за ним.

Чтобы узнать, есть ли какие-либо критические изменения, вы также можете посмотреть раздел «Критические изменения» файла readme пакета.

Обычно файл readme пакета можно найти в:

• Страница пакета npm в реестре npm
• внутри каталога модуля, проверьте node_modules папку внутри проекта
• сайт проекта (или GitHub)

Шаг 3: Обновляйте только один пакет за раз

При обновлении мы должны быть осторожны, чтобы обновить только те пакеты, которые мы хотим. Нет необходимости обновлять все ваши модули одновременно.

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

обновление

npm Изменение версии пакета в файле package.json и запуск npm install , скорее всего, ничего не сделают, поскольку уже установленная версия пакета удовлетворяет управлению версиями в файле package.json.

Rather than using npm install , you can use the обновление command to upgrade already installed packages. When you run a обновление , npm checks if there are newer versions out there that satisfy specified semantic versioning ranges that you specified in package.json and installs them.

Чтобы обновить определенный пакет npm, выполните в консоли следующее:

Как отменить обновления пакета npm?

Если есть какие-либо ошибки, вы можете легко отменить изменения с помощью этих двух команд:

Должна @version быть та же версия, которую вы установили ранее.

Шаг 4: Протестируйте код после установки новых пакетов

Чтобы убедиться, что ваш код по-прежнему работает после обновления пакетов npm, важно протестировать функциональность перед развертыванием. Это связано с тем, что обновление пакета может привести к ошибкам в приложении, если вы не будете осторожны. Чтобы избежать этих проблем, я рекомендую запускать все тесты на стороне сервера и клиента, а также вручную проверять наличие любых сообщений об ошибках JavaScript по всему сайту.

• Выполните все модульные и интеграционные тесты как на стороне сервера, так и на стороне клиента, выполнив npm test аналогичную команду для проекта.
• Просмотрите журналы пакетов на предмет подсказок о том, что вызвало проблему или где что-то пошло не так во время установки

Эти 3 простых шага помогут вам избежать поломки вашего проекта путем тщательной установки новых пакетов npm.

Каковы некоторые из других способов, которыми люди сломали свои проекты? Дайте нам знать в комментариях ниже, и мы напишем сообщение в блоге о них!

Бонусный совет: Очистите кэш

npm Начиная с npm@5, кэш npm самовосстанавливается от проблем с повреждением, и данные, извлеченные из кэша, гарантированно действительны. Если вы хотите убедиться, что все согласовано, используйте вместо этого ‘npm cache verify’. С другой стороны, если вы отлаживаете проблему с установщиком, вы можете npm install —cache /tmp/empty-cache использовать временный кэш вместо того, чтобы использовать фактический кэш.

Иногда npm не извлекает последнюю версию пакета, потому что у него есть более старая версия, хранящаяся в кэше. По состоянию на npm@5 проблем с кэшем не должно возникать. Но они все еще иногда это делают.

To clear npm cache, run npm cache clean —force . This command clears npm’s cache of all the packages that your project has installed with npm install or обновление.

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

Шпаргалка: 6 команд, которые помогут вам обновить пакеты

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

• Use npm list —depth 0 to list all the packages in your package directory
• Use npm аудит to find out which of your npm dependencies are vulnerable.
• Use npm устаревший to list the packages that are out of date with respect to what is installed in package.json
• Use обновление package_name to update an individual package that has already been installed.
• Use npm uninstall package_name and npm install package_name@version to revert to a specific version.
• Use npm cache clean —force to clear npm’s cache of all the packages that have been installed.

Дата: Май 2, 2021

Как обновить или удалить пакет в NPM

Обновляем пакет в NPM до определенной или последней версии, а так же разбираемся как его удалить из проекта.

Дата публикации
8 Марта 2021
Дата изменения
8 Марта 2021
Уникальных просмотров

Оглавление

• Обновление NPM-пакета до нужной версии
• Обновление NPM-пакета до последней версии
• Удаление NPM-пакета из проекта

Для начала необходимо проверить наличие обновлений для пакетов, сделать это можно с помощью команды:

Данная команда выведет вам список пакетов, которые прописаны в вашем package.json и укажет текущую версию и последнюю, до которой можно обновиться.

Пакеты в NPM обновляются с помощью системы семантического версионирования и имеют как правило 3 цифры разделенные точкой.

• Major — версия, когда сделаны обратно несовместимые изменения.
• Minor — версия, когда была добавлена новая функциональность, не нарушающая обратной совместимости.
• Patch — версия, когда были сделаны обратно совместимые исправления (зачастую небольшие исправления багов).

При обновлении major версии пакета, лучше сначала проверить его работоспособность на dev версии проекта. И только после успешных тестов, обновлять на prod версии.

Обновление NPM-пакета до нужной версии

Чтобы обновить пакет до нужной версии, нужно вновь прописать команду npm i myPackageName и после добавить @packageVersion . Например:

npm i myPackage@7.0.0

При этом, не нужно добавлять в команду —save-dev или -D . NPM умный, он просто обновит пакет который записан в devDependencies и не перезапишет его в dependencies или наоборот.

Обновление NPM-пакета до последней версии

Если же вам не нужна определенная версия пакета, то можете просто прописать следующую команду:

npm i myPackage@latest

Данная команда установит последнюю стабильную версию пакета. Однако вам опять стоит обратить внимание на работу пакета, если обновляете major версию.

Удаление NPM-пакета из проекта

Для того чтобы удалить NPM-пакет из проекта, нужно прописать следующую команду:

npm uninstall myPackage

Данная команда удалит как сам пакет, так и все зависимости необходимые для его работы. Пакет будет удален как из файла package.json (из dependencies и devDependencies соответственно), так и из директории node_modules будет удалено все связанное с этим пакетом.

Благодарность автору

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

Один из самых популярных способов поблагодарить автора, воспользоваться сервисом Яндекс.Деньги.