Save dev npm: javascript — В чём отличие npm install —save-dev от —save

Содержание

frontend — Ошибка npm i gulp-sass —save-dev

подскажите, пожалуйста, что делать. или как установить sass

E:\test>npm i gulp-sass —save-dev

npm WARN deprecated [email protected]: request has been deprecated, see https://github.com/request/request/issues/3142
npm WARN deprecated [email protected]: this library is no longer supported

[email protected] install E:\test\node_modules\node-sass

node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.14.1/…
Cannot download «https://github.com/sass/node-sass/releases/download/v4.14.1/…»:

HTTP error 404 Not Found

Hint: If github.com is not accessible in your location

try setting a proxy via HTTP_PROXY, e.g.

export HTTP_PROXY=http://example.com:1234
or configure npm proxy via

npm config set proxy http://example.com:8080

[email protected] postinstall E:\test\node_modules\node-sass

node scripts/build.js

Building: C:\Program Files\nodejs\node.exe E:\test\node_modules\node-gyp\bin\node-gyp.js rebuild —verbose —libsass_ext= —libsass_cflags= —libsass_ldflags= —libsass_library=

gyp info it worked if it ends with ok

gyp verb cli [

gyp verb cli ‘C:\Program Files\nodejs\node.exe’,

gyp verb cli ‘E:\test\node_modules\node-gyp\bin\node-gyp.js’,

gyp verb cli ‘rebuild’,

gyp verb cli ‘—verbose’,

gyp verb cli ‘—libsass_ext=’,

gyp verb cli ‘—libsass_cflags=’,

gyp verb cli ‘—libsass_ldflags=’,

gyp verb cli ‘—libsass_library=’

gyp verb cli ]

gyp info using [email protected]

gyp info using [email protected] | win32 | x64

gyp verb command rebuild []

gyp verb command clean []

gyp verb clean removing «build» directory

gyp verb command configure []

gyp verb check python checking for Python executable «python2» in the PATH

gyp verb which failed Error: not found: python2

gyp verb which failed at getNotFoundError (E:\test\node_modules\which\which.js:13:12)

gyp verb which failed at F (E:\test\node_modules\which\which.js:68:19)

gyp verb which failed at E (E:\test\node_modules\which\which.js:80:29)

gyp verb which failed at E:\test\node_modules\which\which.js:89:16

gyp verb which failed at E:\test\node_modules\isexe\index.js:42:5

gyp verb which failed at E:\test\node_modules\isexe\windows.js:36:5

gyp verb which failed at FSReqCallback.oncomplete (node:fs:183:21)

gyp verb which failed python2 Error: not found: python2

gyp verb which failed at getNotFoundError (E:\test\node_modules\which\which.js:13:12)

gyp verb which failed at F (E:\test\node_modules\which\which.js:68:19)

gyp verb which failed at E (E:\test\node_modules\which\which.js:80:29)

gyp verb which failed at E:\test\node_modules\which\which.js:89:16

gyp verb which failed at E:\test\node_modules\isexe\index.js:42:5

gyp verb which failed at E:\test\node_modules\isexe\windows.js:36:5

gyp verb which failed at FSReqCallback.oncomplete (node:fs:183:21) {

gyp verb which failed code: ‘ENOENT’

gyp verb which failed }

gyp verb check python checking for Python executable «python» in the PATH

gyp verb which failed Error: not found: python

gyp verb which failed at getNotFoundError (E:\test\node_modules\which\which.js:13:12)

gyp verb which failed at F (E:\test\node_modules\which\which.js:68:19)

gyp verb which failed at E (E:\test\node_modules\which\which.js:80:29)

gyp verb which failed at E:\test\node_modules\which\which.js:89:16

gyp verb which failed at E:\test\node_modules\isexe\index.js:42:5

gyp verb which failed at E:\test\node_modules\isexe\windows.js:36:5

gyp verb which failed at FSReqCallback.oncomplete (node:fs:183:21)

gyp verb which failed python Error: not found: python

gyp verb which failed at getNotFoundError (E:\test\node_modules\which\which.js:13:12)

gyp verb which failed at F (E:\test\node_modules\which\which.js:68:19)

gyp verb which failed at E (E:\test\node_modules\which\which.js:80:29)

gyp verb which failed at E:\test\node_modules\which\which.js:89:16

gyp verb which failed at E:\test\node_modules\isexe\index.js:42:5

gyp verb which failed at E:\test\node_modules\isexe\windows.js:36:5

gyp verb which failed at FSReqCallback.oncomplete (node:fs:183:21) {

gyp verb which failed code: ‘ENOENT’

gyp verb which failed }

gyp verb could not find «python». checking python launcher

gyp verb could not find «python». guessing location

gyp verb ensuring that file exists: C:\Python27\python.exe

gyp ERR! configure error

gyp ERR! stack Error: Can’t find Python executable «python», you can set the PYTHON env variable.

gyp ERR! stack at PythonFinder.failNoPython (E:\test\node_modules\node-gyp\lib\configure.js:484:19)

gyp ERR! stack at PythonFinder. (E:\test\node_modules\node-gyp\lib\configure.js:509:16)

gyp ERR! stack at callback (E:\test\node_modules\graceful-fs\polyfills.js:295:20)

gyp ERR! stack at FSReqCallback.oncomplete (node:fs:183:21)

gyp ERR! System Windows_NT 10.0.19041

gyp ERR! command «C:\Program Files\nodejs\node.exe» «E:\test\node_modules\node-gyp\bin\node-gyp.js» «rebuild» «—verbose» «—libsass_ext=» «—libsass_cflags=» «—libsass_ldflags=» «—libsass_library=»

gyp ERR! cwd E:\test\node_modules\node-sass

gyp ERR! node -v v15.1.0

gyp ERR! node-gyp -v v3.8.0

gyp ERR! not ok

Build failed with error code: 1

npm WARN enoent ENOENT: no such file or directory, open ‘E:\test\package.json’

npm WARN test No description

npm WARN test No repository field.

npm WARN test No README data

npm WARN test No license field.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):

npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {«os»:»darwin»,»arch»:»any»} (current: {«os»:»win32″,»arch»:»x64″})

npm ERR! code ELIFECYCLE

npm ERR! errno 1

npm ERR! [email protected] postinstall: node scripts/build.js

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the [email protected] postinstall script.

npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

Несколько полезностей по работе с NPM / Хабр

NPM — пакетный менеджер для node.js, аналог GEM в RoR. В статье несколько советов по его использованию.

Установка пакетов

Все знают

# Устанавливает пакет express
npm install express

Какие варианты еще есть?

# Устанавливает все пакеты, перечисленные в package.json
npm install

# Устанавливает express и вносит запись о нем в package.json в секцию dependencies
npm install express --save

# Устанавливает grunt и вносит запись о нем в package.json в секцию devDependencies
npm install grunt --save-dev

Варианты с —save и —save-dev сделают запись в package.json только, если он уже существует.

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

# Все - теперь все устанавливаемый пакеты будут автоматом прописываться в package.json
npm config set save true

Кстати, насчет —save

# Кроме того, что все пакеты обновятся, если в package.json в качестве 
# версии была прописана "*" - теперь туда попадут конкретные версии
npm update --save

Сокращенные варианты команд

Для ускорения процесса ввода команд удобно использовать сокращения. Самое полезное в виде таблички:

Ключ	Сокращение
install	i
uninstall	r
config	c
update	up
list	ls
—save	-S
—save-dev	-D

Пример:

npm install express --save

# Совершенно то же самое

npm i express -S

Подготовка к npm init

Не очень удобно при создании package.json при помощи npm init каждый раз вводить персональные данные. Чтобы этого избежать, сделаем настройку:

# Внесем информацию об авторе "по умолчанию"
npm set init.author.name "$NAME"
npm set init.author.email "$EMAIL"
npm set init.author.url "$SITE"

Вместо переменных среды $NAME и т.д. можно внести и сами данные. Все, теперь мы готовы к npm init

А что еще можно настраивать?

# Выведет список всех возможных настроек
npm config ls -l

Проверить, не устарели ли пакеты

# Бывает полезно сделать прежде чем делать update
npm outdated

Фиксируем версии пакетов

# Все, можно передавать в продакшен
npm shrinkwrap

Прежде чем передавать продукт в промышленную эксплуатацию, по хорошему, нужно зафиксировать точные версии пакетов с которыми все 100% работает. Эта команда так и сделает. После ее выполнения будет создан shrinkwrap.json, в котором будут прописаны точные версии ваших пакетов, теперь npm install будет устанавливать именно их.

Обновление версии NPM

# NPM вполне может обновлять сама себя
npm update npm -g

P.S. Я здесь новичок, если карму минусуете, то хоть пишите, что не так

Зачем нужен npm —save-dev — CodeRoad

При установке пакетов в npm, почему мы должны добавить --save-dev в конце?

Пример:

npm install gulp-angular-templatecache --save-dev

В документации онлайн ( https: / / docs.npmjs.com/cli/install) говорится: «пакет появится в вашем devDependencies .» Что это значит? Значит ли это, что если я не поставлю --save-dev , он будет установлен в другой каталог?

node.js

npm

Поделиться

Источник

user1995781

12 января 2015 в 07:16

2 ответа

Разница между npm install —save и npm install —save-dev
Ребята, я знаю, что с помощью npm install -g мы можем установить модули/пакеты узлов глобально, но я не уверен в опциях —save и —save-dev Я погуглил его, но все еще не совсем понял. Пожалуйста, поделитесь своими мыслями.
npm install packagename —save-dev не обновляется package.json
Есть ли простые или тонкие причины, по которым package.json не будет обновляться после запуска —save-dev? Это мой приказ: npm install modulename —save-dev Запуск из корня проекта. Команда выполнена успешно, новый модуль появляется в каталоге node_modules, как и ожидалось. Помощь будет…

package.json имеет два места для хранения информации о зависимостях: объект «dependencies» и объект «devDependencies».

Когда вы устанавливаете приложение и запускаете «npm install», оно снимает как зависимости, так и devDependencies. Однако, если вы сделаете «npm install —production», он уберет ONLY зависимости, NOT-devDependencies.

Идея заключается в том, что devDependencies предназначены для таких вещей, как тестовые раннеры и библиотеки утверждений; вещи, которые вам нужны во время разработки, но не те, которые вам нужны, когда вы фактически развернули приложение в производство.1.5.0″
},
…
}

Поделиться

Patrick Roberts

12 января 2015 в 07:21

Разница между npm install —save и npm install —save-dev

Ребята, я знаю, что с помощью npm install -g мы можем установить модули/пакеты узлов глобально, но я не уверен в опциях --save и --save-dev

Я погуглил его, но все еще не совсем понял. Пожалуйста, поделитесь своими мыслями.

javascript

npm

Поделиться

Источник

Vinay Singh

10 октября 2015 в 14:59

3 ответа

В чем разница между —save и —save-dev?
В чем разница между ними: npm install [package_name] —save и: npm install [package_name] —save-dev Что это значит?
npm install —save, какой смысл не сохранять
Я понимаю разницу между npm install something и npm install something —save (для тех, кому интересно, первый установит зависимость только тогда, когда последний установит зависимость и добавит ее к вашему package.json). Однако я не понимаю, почему существует опция —save в первую очередь. Другими…

--save добавляет сторонний пакет к зависимостям пакета . Он будет установлен вместе с пакетом всякий раз, когда кто-то запускает npm install yourPackage .

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

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

Оба типа зависимостей хранятся в файле package.json пакета. --save добавляет к dependencies, --save-dev добавляет к devDependencies . Из документации :

devDependencies
Если кто-то планирует загрузить и использовать ваш модуль в своей программе, то он, вероятно, не хочет или не нуждается в загрузке и создании внешнего тестового или документационного фреймворка, который вы используете.
В этом случае лучше всего сопоставить эти дополнительные элементы в объекте devDependencies.
Эти вещи будут установлены при выполнении npm link или npm install из корня пакета, и ими можно управлять, как и любым другим параметром конфигурации npm. Увидеть npm-конфиг(7) Для больше на этой теме.
Для шагов сборки, не зависящих от платформы, таких как компиляция CoffeeScript или других языков в JavaScript, используйте для этого сценарий prepublish и сделайте необходимый пакет devDependency.

Правка: по состоянию на npm 5.0.0 установленных модулей добавляются в качестве зависимостей по умолчанию, так … сохранить вариант отпадает.

Поделиться

Felix Kling

10 октября 2015 в 15:06

--save-dev используется для сохранения пакета в целях разработки. Пример: модульные тесты, минификация.
--save используется для сохранения пакета, необходимого для запуска приложения.

Поделиться

kattybilly

02 апреля 2016 в 07:02

--save-dev сохранит npm модуля в зависимостях разработки в package.json, то есть сохранит внутри объекта devDependencies.
--save сохранит npm зависимости модулей в package.json, то есть сохранит внутри объекта зависимостей.

Поделиться

Slim Coder

09 марта 2020 в 14:52

Что делают флаги —save с npm install
Я вижу инструкции по установке пакета с любым из них npm install <package_name> или npm install <package_name> —save или npm install <package_name> —save-dev В чем разница между этими вариантами?
Ошибка при установке npm install grunt-contrib-clean —dev-save
Вот файл package.0.5.0 } } Имея этот файл package.json , при установке…

node.js — В чем разница между —save и —save-dev в npm install?

dependencies — это модули, от которых зависит ваш проект, devDependencies — это модули, которые вы используете для разработки своего проекта. Вы можете прочитать подробное описание на веб-сайте npmjs :

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


В этом случае лучше сопоставить эти дополнительные элементы в
  объект devDependencies.

Примеры зависимостей: request, concat-stream, object.assign, through3.

Примеры devDependencies: mocha, tape, eslint, grunt, —- +: = 10 =:. + —-

зависимости всегда устанавливаются всякий раз, когда ваш проект установлен или инициализирован, они необходимы для работы вашего проекта. devDependencies предназначены только для разработки (среда тестирования, исполнитель задач …) и устанавливаются только тогда, когда кто-то запускает browserify из корня проекта. Например, после клонирования репозитория проекта.

Вы можете легко это проверить. Предположим, у меня есть модули npm install, foo, bar и baz в том же каталоге , Пусть quux будет зависимостью от foo, baz быть devDependency bar, и baz сама будет зависимостью от baz.

quux

Как видите, установлены как зависимости, так и devDependencies.

Теперь давайте установим #/$ cd baz #/baz$ cat package.json { "name": "baz", "version": "0.0.0", "dependencies": { "foo": "../foo" }, "devDependencies": { "bar": "../bar" } } #/baz$ npm install [email protected] /tmp/tmpdir/g6jBr9/baz ├── [email protected] └── [email protected] как зависимость baz:

quux

Обратите внимание, что #/$ cd quux #/quux$ cat package.json { "name": "quux", "version": "0.0.0", "dependencies": { "baz": "../baz" } } #/quux$ npm install #/quux$ npm ls [email protected] /tmp/tmpdir/g6jBr9/quux └─┬ [email protected] └── [email protected] установлен, но foo нет. Это потому, что если вам требуется какой-то модуль в качестве зависимости от другого модуля (т.е. вы являетесь потребителем этого модуля), вам не нужны его devDependencies, потому что они не нужны для работы модуля. .

Использование модулей Node.js с npm и package.json

Автор выбрал фонд Open Internet/Free Speech для получения пожертвования в рамках программы Write for DOnations.

Введение

Благодаря таким функциям, как оперативное выполнение ввода/вывода и его широко известному синтаксису JavaScript, Node.js быстро стал популярной рабочей средой для разработки веб-приложений на стороне сервера. Но по мере роста интереса создаются более крупные приложения, а управление сложностью базы кода и ее зависимостей становится сложнее. Node.js организует эти сложные процессы с помощью модулей, которые являются любым отдельным файлом JavaScript, содержащим функции или объекты, используемые другими программами или модулями. Группа из одного или нескольких модулей часто называется пакетом, а эти пакеты организованы менеджерами пакетов.

Менеджер пакетов Node.js (npm) — это стандартный и наиболее популярный менеджер пакетов в экосистеме Node.js; он преимущественно используется для установки и управления внешними модулями проекта Node.js. Он также часто используется для установки широкого спектра инструментов командной строки и запуска скриптов проекта. npm отслеживает модули, установленные в проекте с файлом package.json, находящимся в директории проекта и содержащим следующее:

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

При создании более сложных проектов Node.js управление своими метаданными и зависимостями при помощи файла package.json позволит обеспечить более предсказуемые сборки, поскольку все внешние зависимости одинаковы. Файл будет автоматически отслеживать эту информацию. Хотя вы можете изменять файл напрямую для обновления метаданных вашего проекта, вам будет редко требоваться взаимодействовать с ним напрямую для управления модулями.

В этом обучающем руководстве вы будете управлять пакетами с помощью npm. Первый шаг будет состоять в создании и понимании файла package.json. Затем вы сможете использовать его для отслеживания всех модулей, которые вы установили в вашем проекте. В заключение вы укажете зависимости пакетов, обновите пакеты, удалите пакеты и проведете проверку на предмет уязвимостей безопасности.

Предварительные требования

Для данного обучающего руководства вам потребуется следующее:

Node.js, установленный на вашем компьютере для разработки. В этом обучающем руководстве используется версия 10.17.0. Чтобы установить его в macOS или Ubuntu 18.04, следуйте указаниям руководства Установка Node.js и создание локальной среды разработки в macOS или раздела Установка с помощью PPA руководства Установка Node.js в Ubuntu 18.04. При установке Node.js также выполняется установка npm, в этом обучающем руководстве используется версия 6.11.3.

Шаг 1 — Создание файла

package.json

Начнем это обучающее руководство с проекта в качестве примера — гипотетический модуль локатора Node.js, получающий IP-адрес пользователя и возвращающий страну происхождения. Вы не будете кодировать модуль в этом обучающем руководстве. Однако пакеты, которыми вы управляете, будут актуальны, если вы их разрабатывали.

Вначале вы создадите файл package.json, который будет содержать полезные метаданные проекта и поможет вам управлять зависимыми модулями Node.js проекта. Как следует из названия суффикса, это файл JSON (обозначение объектов JavaScript). JSON — стандартный формат, используемый для обмена, основанный на объектах JavaScript и состоящий из данных, сохраненных как пары «ключ-значение». Если хотите узнать больше о JSON, ознакомьтесь с нашей статьей Введение в JSON.

Поскольку файл package.json содержит многочисленные свойства, может быть затруднительно создавать его вручную без копирования и вставки шаблона из другого места. Чтобы упростить процесс, npm предоставляет команду init. Это интерактивная команда, которая задает ряд вопросов и создает файл package.json на основе ваших ответов.

Использование команды

init

Вначале настройте проект, чтобы можно было попрактиковаться в управлении модулями. В своей оболочке создайте новую папку под названием locator:

Затем перейдите в новую папку:

Теперь инициализируйте интерактивную командную строку, введя следующее:

Примечание. Если ваш код будет использовать Git для контроля версий, сначала создайте репозиторий Git, а затем запустите npm init. Команда автоматически понимает, что она находится в папке, управляемой Git. Если задан удаленный Git, он автоматически заполняет следующие поля для вашего файла package.json: repository, bugs и homepage. Если вы инициализировали репозиторий после создания файла package.json, вам нужно будет добавить эту информацию самостоятельно. Дополнительную информацию по контролю версий Git можно найти в нашей серии Введение в Git: установка, использование и ответвления.

Результат будет выглядеть следующим образом:

OutputThis utility will walk you through creating a package.json file.
It only covers the most common items, and tries to guess sensible defaults.

See `npm help json` for definitive documentation on these fields
and exactly what they do.

Use `npm install <pkg>` afterwards to install a package and
save it as a dependency in the package.C at any time to quit.
package name: (locator)

Сначала вам будет предложено ввести имя нового проекта. По умолчанию команда предполагает, что это имя папки, в которой вы находитесь. Значения по умолчанию для каждого свойства показаны в скобках (). Поскольку в настоящем руководстве будет использоваться значение имени по умолчанию, нажмите ENTER, чтобы принять его.

Следующее значение, которое нужно ввести — версия. Как и в случае с именем, это поле требуется, если ваш проект будет размещаться вместе с другими проектами в репозитории пакетов npm.

Примечание. Пакеты Node.js должны соответствовать руководству по указанию версий Semantic (semver). Поэтому первое число будет номером версии MAJOR, который изменяется только при изменении API. Второе число будет номером версии MINOR, который изменяется при добавлении функций. Последнее число будет номером версии PATCH, который изменяется при исправлении ошибок.

Нажмите ENTER, чтобы принять версию по умолчанию.

Следующее поле описание — полезная строка, чтобы объяснить, что делает ваш модуль Node.js. Наш проект гипотетического локатора получит IP-адрес пользователя и выдаст страну происхождения. Подходящее описание: находит страну происхождения по входящему запросу, поэтому введите нечто подобное и нажмите ENTER. Описание очень полезно, когда люди ищут ваш модуль.

Следующая строка запросит у вас точку входа. Если кто-то осуществляет установку и нуждается в вашем модуле, то указанное вами в точке входа будет первой частью вашей загружаемой программы. Значение должно быть относительным местом расположения файла JavaScript и будет добавлено в свойство main файла package.json. Нажмите ENTER, чтобы сохранить значение по умолчанию.

Примечание. В большинстве модулей файл index.js является основной точкой входа. Это значение по умолчанию для свойства main файла package.json, которое представляет собой точку входа для модулей npm. Если не будет package.json, Node.js попробует загружать index.js по умолчанию.

Далее вам нужно будет ввести команду test, исполняемый скрипт или команду, чтобы запустить тесты проекта. Во многих популярных модулях Node.js тесты написаны и осуществляются с помощью Mocha, Jest, Jasmine или других тестовых структур. Поскольку тестирование выходит за рамки этой статьи, оставьте эту опцию пустой и нажмите ENTER, чтобы продолжить.

Затем команда init запросит репозиторий GitHub проекта. Вы не будете использовать его в данном примере, поэтому оставьте и его пустым.

После строки репозитория команда запросит ключевые слова. Это свойство представляет собой массив строк с полезными терминами, которые можно использовать для поиска репозитория. Лучше всего иметь небольшой набор слов, которые наиболее актуальны для вашего проекта, чтобы обеспечить более целенаправленный поиск. Введите эти ключевые слова как строку с запятыми, разделяющими каждое значение. Для данного проекта, служащего примером, введите ip,geo,country в командной строке. В готовом package.json будет три элемента в массиве для ключевых слов.

Следующее поле в командной строке — автор. Это полезно для пользователей вашего модуля, которые хотят связаться с вами. Например, если кто-то обнаружит средство эксплуатации уязвимостей в вашем модуле, они смогут использовать это поле, чтобы сообщить о проблеме, чтобы вы смогли ее исправить. Поле автор представляет собой строку в следующем формате: "Name \<Email\> (Website)". Например, "Sammy \<sammy@your_domain\> (https://your_domain)" — подходящее значение поля «автор». Электронная почта и веб-сайт являются опциональными данными — подходящее значение поля «автор» может состоять только из имени. Добавьте ваши контактные данные в качестве автора и подтвердите нажатием ENTER.

В заключение вам будет предложено ввести лицензию. Это определяет юридические разрешения и ограничения, которые будут у пользователей при использовании вашего модуля. Многие модули Node.js имеют открытый исходный код, поэтому npm задает значение ISC по умолчанию.

К этому моменту вы должны будете рассмотреть ваши опции лицензирования и определить, что подходит лучше всего для вашего проекта. Дополнительную информацию по различным видам открытых лицензий можно найти в этом списке лицензий от организации Open Source Initiative. Если вы не захотите предоставлять лицензию для частного репозитория, вы можете ввести UNLICENSED в командной строке. Для данного примера используйте лицензию ISC по умолчанию и нажмите ENTER, чтобы завершить этот процесс.

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

OutputAbout to write to /home/sammy/locator/package.json:

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy <sammy@your_domain> (https://your_domain)",
  "license": "ISC"
}


Is this OK? (yes)

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

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

`Шаг 2 — Установка модулей`

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

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

Рассмотрим это на примере. В вашем приложении локатора вы будете использовать библиотеку axios, которая поможет вам выполнять запросы HTTP. Установите ее, введя следующее в оболочке:

Вы начинаете эту команду с npm install — это установит данный пакет (для краткости можно использовать npm i). Затем перечисляете пакеты, которые хотите установить, разделяя их пробелом. В этом случае это axios. В заключение вы заканчиваете команду опциональным параметром --save, который указывает, что axios будет сохранен как зависимость проекта.

После установки библиотеки вы увидите примерно следующее:

Output...
+ [email protected]
added 5 packages from 8 contributors and audited 5 packages in 0.764s
found 0 vulnerabilities

Теперь откройте файл package.json в текстовом редакторе по вашему выбору. В этом обучающем руководстве мы будем использовать nano:

Вы увидите новое свойство, как подчеркнуто ниже:

locator/package.json

{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0. означает, что любая более высокая версия MINOR или PATCH удовлетворит это ограничение версии. Если видите ~ в начале номера версии, это означает, что только более высокие номера версий PATCH удовлетворяют это ограничение.


После завершения просмотра package.json выйдите из файла.

Зависимости разработки

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

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

Установите инструмент статического анализа кода в качестве зависимости разработки для вашего проекта. Попробуйте это в оболочке:
npm i [email protected] --save-dev
В этой команде вы использовали флаг --save-dev. Это сохранит eslint как зависимость, которая необходима только для разработки. Обратите внимание, что вы добавили @6.0.0 к своему имени зависимости. После обновления модулей на них ставится тег версии. @ указывает npm искать конкретный тег модуля, который вы устанавливаете. Без указанного тега npm устанавливает последнюю версию с тегами. Откройте package.json еще раз:
В результате вы получите следующий вывод:
locator/package.json
{
  "name": "locator",
  "version": "1.0.0",
  "description": "Finds the country of origin of the incoming request",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [
    "ip",
    "geo",
    "country"
  ],
  "author": "Sammy sammy@your_domain (https://your_domain)",
  "license": "ISC",
  "dependencies": {
    "axios": "^0.6.0.0"
  }
}
eslint сохранился как devDependencies, вместе с номером версии, который вы указали ранее. Выйдите из package.json.
Автоматически сгенерированные файлы: 
node_modules и package-lock.json
Когда вы в первый раз устанавливаете пакет в проекте Node.js, npm автоматически создает папку node_modules для хранения модулей, необходимых для вашего проекта, и файл package-lock.json, который вы проверили ранее.
Подтвердите, что они находятся в вашей рабочей директории. В вашей оболочке введите ls и нажмите ENTER. Результат будет выглядеть следующим образом:
Outputnode_modules    package.json    package-lock.json
Папка node_modules содержит все установленные зависимости для вашего проекта. В большинстве случаев вы не должны назначать эту папку вашему репозиторию с контролем версии. По мере того как вы будете устанавливать больше зависимостей, размер этой папки будет быстро расти. Кроме того, файл package-lock.json хранит записи точных версий, установленных более сжато, поэтому включение node_modules не требуется.
Хотя файл package.json перечисляет зависимости, которые указывают нам на соответствующие версии, которые должны быть установлены для проекта, файл package-lock.json отслеживает все изменения в package.json или node_modules и указывает на конкретную версию установленного пакета. Обычно вы управляете этим в вашем репозитории с контролем версий, а не в node_modules, т. к. это более прозрачное представление всех ваших зависимостей.
Установка из package.json
С помощью ваших файлов package.json и package-lock.json вы можете быстро задать те же самые зависимости проекта, прежде чем начать разработку нового проекта. Чтобы продемонстрировать это, перейдите на один уровень выше в дереве директорий и создайте новую папку с именем cloned_locator на том же уровне директории, что и locator:
cd ..
mkdir cloned_locator
Перейдите в новую директорию:
Теперь скопируйте файлы package.json и package-lock.json из locator в cloned_locator:
cp ../locator/package.json ../locator/package-lock.json .
Чтобы установить требуемые модули для этого проекта, введите следующее:
npm проверит файл package-lock.json, чтобы установить модули. Если файл lock недоступен, он будет читать из файла package.json, чтобы определить установки. Обычно быстрее устанавливать из package-lock.json, поскольку файл lock содержит точные версии модулей и их зависимости, что означает, что npm может не тратить время на нахождение подходящей версии для установки.
При развертывании в производственную среду вы можете пропустить зависимости разработки. Вспомните, что зависимости разработки хранятся в разделе devDependencies файла package.json и не влияют на управление вашим приложением. При установке модулей в рамках процесса непрерывной интеграции и разработки, чтобы развернуть приложение, пропустите зависимости разработки, введя следующее:
Флаг --production игнорирует раздел devDependencies во время установки. Пока что перейдите к вашей сборке разработки.
Прежде чем перейти к следующему разделу, вернитесь в папку locator:
Глобальная установка
Пока что вы устанавливали модули npm для проекта locator. npm также позволяет устанавливать пакеты на глобальном уровне. Это означает, что пакет доступен вашему пользователю в более широкой системе, как и любая другая команда оболочки. Эта способность полезна для многих модулей Node.js, которые являются инструментами командной строки.
Например, вы хотите завести блог о проекте locator, над которым вы сейчас работаете. Для этого вы можете использовать библиотеку, например Hexo, для создания и управления вашим блогом на статичном веб-сайте. Установите командную строку Hexo на глобальном уровне следующим образом:
Чтобы установить пакет на глобальном уровне, вы добавляете флаг -g к команде.
Примечание. Если вы получите ошибку разрешений, пытаясь выполнить установку этого пакета на глобальном уровне, ваша система может потребовать права суперпользователя для запуска команды. Попробуйте еще раз команду sudo npm i hexo-cli -g.
Проверьте, что пакет успешно установлен, введя следующее:
Вы увидите примерно следующий результат:
Outputhexo-cli: 2.0.0
os: Linux 4.15.0-64-generic linux x64
http_parser: 2.7.1
node: 10.14.0
v8: 7.6.303.29-node.16
uv: 1.31.0
zlib: 1.2.11
ares: 1.15.0
modules: 72
nghttp2: 1.39.2
openssl: 1.1.1c
brotli: 1.0.7
napi: 4
llhttp: 1.1.4
icu: 64.2
unicode: 12.1
cldr: 35.1
tz: 2019a
На данный момент вы узнали, как устанавливать модули с помощью npm. Вы можете установить пакеты к проекту локально —либо как зависимость в производственной среде, либо как зависимость разработки. Также вы можете устанавливать пакеты на базе уже существующих файлов package.json или package-lock.json, что позволяет разрабатывать с теми же зависимостями, что и у ваших коллег. В заключение вы можете использовать флаг -g для установки пакетов на глобальном уровне, чтобы получить доступ к ним, независимо от того, находитесь ли вы в проекте Node.js или нет.
Теперь, когда вы можете устанавливать модули, в следующем разделе вы будете практиковать методы управления своими зависимостями.
Шаг 3 — Управление модулями
Полный менеджер пакетов способен на гораздо большее, чем установка модулей. В npm имеется 20 команд, связанных с управлением зависимостями. На этом шаге вы:
Укажете модули, которые вы установили.
Обновите модули до последней версии.
Удалите модули, которые вам больше не нужны.
Проведете проверку безопасности на ваших модулях, чтобы найти и исправить ошибки безопасности.
Хотя эти примеры будут сделаны в вашей папке locator, все эти команды могут запускаться на глобальном уровне посредством добавления флага -g в конце, как и в случае установки на глобальном уровне.
Указание модулей
Если вы хотите знать, какие модули установлены в проекте, проще использовать команду list или ls вместо чтения package.json напрямую. Для этого введите следующее:
Результат должен выглядеть следующим образом:
Output
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ └─┬ [email protected]
│ │   └── [email protected]
│ └── [email protected]
└─┬ [email protected]
  ├─┬ @babel/[email protected]
  │ └─┬ @babel/[email protected]
  │   ├── [email protected] deduped
  │   ├── [email protected] deduped
  │   └── [email protected]
  ├─┬ [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ ├── [email protected]
  │ └─┬ [email protected]
...
По умолчанию ls отображает все дерево зависимостей — модули, от которых зависит ваш проект, и модули, от которых зависят ваши зависимости. Это может быть довольно неудобно, если вы хотите получить общий обзор того, что установлено.
Чтобы вывести только модули, которые вы установили, без их зависимостей, введите следующее в оболочке:
Результат будет выглядеть следующим образом:
Output
├── [email protected]
└── [email protected]
Опция --depth позволяет указать, какой уровень дерева зависимостей вы хотите увидеть. Когда значение 0, вы увидите только зависимости самого высокого уровня.
Обновление модулей
Это хорошая практика, позволяющая поддерживать ваши модули npm обновленными. Это повышает вашу вероятность получения последних исправлений безопасности для модуля. Используйте команду outdated, чтобы проверить, можно ли обновить какие-либо модули:
Вывод будет выглядеть следующим образом:
OutputPackage  Current  Wanted  Latest  Location
eslint     6.0.0   6.7.1   6.7.1  locator
Сначала эта команда указывает пакет (Package), который установлен, и текущую (Current) версию. В столбце Wanted показано, какая версия удовлетворяет вашему требованию версии в package.json. В столбце Latest показана самая последняя опубликованная версия модуля.
В столбце Location показано, где в дереве зависимостей находится пакет. Команда outdated имеет флаг --depth, как ls. По умолчанию depth равняется 0.
Похоже, вы можете обновить eslint до последней версии. Используйте команду update или up следующим образом:
Вывод команды будет содержать установленную версию:
Output
npm WARN [email protected] No repository field.

+ [email protected]
added 7 packages from 3 contributors, removed 5 packages, updated 19 packages, moved 1 package and audited 184 packages in 5.818s
found 0 vulnerabilities
Если хотите обновить все модули одновременно, введите следующее:
Удаление модулей
Команда npm uninstall может удалять модули из ваших проектов. Это означает, что модуль больше не будет установлен в папке node_modules и его нельзя будет увидеть в ваших файлах package.json и package-lock.json.
Удаление зависимостей из проекта — обычное мероприятие в жизненном цикле разработки программного обеспечения. Зависимость может не решить проблему, как заявлено, или может не предоставить удовлетворительный опыт разработки. В этих случаях может быть лучше удалить зависимость и создать собственный модуль.
Представьте, что axios не предоставляет опыт разработки, который вы хотели бы иметь для выполнения запросов HTTP. Удалите axios с помощью команды uninstall или un, введя следующее:
Вывод будет выглядеть следующим образом:
Output
npm WARN [email protected] No repository field.

removed 5 packages and audited 176 packages in 1.488s
found 0 vulnerabilities
Здесь не указано явно, что axios был удален. Чтобы убедиться, что он был удален, еще раз укажите зависимости:
Теперь мы видим только то, что установлен eslint:
Output
└── [email protected]
Это показывает, что вы успешно удалили пакет axios.
Проверка модулей
npm предоставляет команду audit, чтобы выявить потенциальные риски безопасности в ваших зависимостях. Чтобы увидеть проверку в действии, установите устаревшую версию модуля request, выполнив следующее:
После установки устаревшей версии request вы должны увидеть примерно следующий результат:
Output
+ [email protected]
added 54 packages from 49 contributors and audited 243 packages in 7.26s
found 6 moderate severity vulnerabilities
  run `npm audit fix` to fix them, or `npm audit` for details
npm указывает, что у вас есть уязвимости в ваших зависимостях. Для получения более подробных сведений проверьте весь ваш проект:
Команда audit показывает таблицы вывода, указывающие на недостатки безопасности:
Output                       === npm audit security report ===

# Run  npm install [email protected]  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Memory Exposure                                              │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tunnel-agent                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request > tunnel-agent                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/598                             │
└───────────────┴──────────────────────────────────────────────────────────────┘

# Run  npm update request --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ Remote Memory Exposure                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ request                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/309                             │
└───────────────┴──────────────────────────────────────────────────────────────┘
...
Вы видите путь к уязвимости, и иногда npm предоставляет способы ее устранения. Вы можете выполнить команду update, как предложено, или выполнить подкоманду fix команды audit. В своей оболочке введите:
Вы увидите примерно следующий результат:
Output
+ [email protected]
added 19 packages from 24 contributors, removed 32 packages and updated 12 packages in 6.223s
fixed 2 of 6 vulnerabilities in 243 scanned packages
  4 vulnerabilities required manual review and could not be updated
npm смог безопасно обновить два пакета, тем самым устранив две уязвимости. Но у вас все еще есть четыре уязвимости в ваших зависимостях. Команда audit fix не всегда устраняет каждую проблему. Хотя версия модуля может иметь уязвимость безопасности, если вы обновите ее до версии с другим API, то это может нарушить код выше в дереве зависимостей.
Вы можете использовать параметр --force, чтобы обеспечить удаление уязвимости:
Как упоминалось ранее, это не рекомендуется, если вы не уверены, что это не нарушит функциональность.
Заключение
В этом обучающем руководстве вы прошли различные упражнения, чтобы продемонстрировать организацию модулей Node.js в пакетах и управление этими пакетами при помощи npm. В проекте Node.js вы использовали пакеты npm как зависимости, создавая и обслуживая файл package.json — запись метаданных вашего проекта, включая модули, которые вы установили. Вы также использовали инструмент командной строки npm для установки, обновления и удаления модулей, помимо указания дерева зависимостей для ваших проектов, а также проверки и обновления модулей, которые устарели.
В будущем использование существующего кода с помощью модулей ускорит время разработки, так как вам не придется дублировать функциональность. Вы также сможете создавать собственные модули npm, и они, в свою очередь, будут управляться другими модулями с помощью команд npm. В качестве дальнейших шагов экспериментируйте с тем, что вы узнали в этом обучающем руководстве, устанавливая и тестируя различные существующие пакеты. Посмотрите, что предоставляет экосистема для упрощения процесса решения проблем. Например, вы можете попробовать TypeScript — расширенную версию JavaScript, или превратить ваш веб-сайт в мобильные приложения с помощью Cordova. Если хотите узнать больше о Node.js, ознакомьтесь с другими нашими обучающими руководствами по Node.js.
Начало работы · Jest
Установите Jest с помощью yarn:
Или npm:
Примечание: документация Jest использует команды yarn, но npm также будет работать. Вы можете сравнить команды yarn и npm в документации yarn, здесь.
Для начала напишем тест для функции, которая складывает два числа. Во-первых создайте файл sum.js:
Затем создайте файл с именем sum.test.js. Он будет содержать сам тест:
Добавьте следующий раздел в package.json:
Наконец, запустите yarn test или npm run test и Jest выведет это сообщение:
Вы только что успешно написали первый тест с использованием Jest!
Данный тест использует expect и toBe для проверки идентичности двух данных значений. Чтобы узнать об остальных вещах, которые можно протестировать с использованием Jest, смотрите использование сопоставлений.
Запуск из командной строки#
Вы можете запустить Jest прямо из командной строки (если он глобально доступен в PATH, например yarn global add jest или npm install jest --global) с множеством полезных опций.
Вот так можно запустить Jest для проверки файлов совпадающих с my-test, используя config.json в качестве файла конфигурации и для отображения нативного уведомления ОС после завершения:
Если вы хотите узнать больше о работе с jest в командной строке, обратите внимание на страницу параметров командной строки Jest.
Дополнительная конфигурация#
Создание базового файла конфигурации#
Исходя из ваших нужд, Jest задаст вам несколько вопросов и создаст базовый файл конфигурации с кратким описанием для каждой опции:
С использованием Babel#
Для использования Babel, установите необходимые зависимости через yarn:
Настройте Babel на вашу текущую версию Node Js, создав файл babel.config.js в корне вашего проекта:
Идеальная конфигурация для Babel будет зависеть от вашего проекта. Смотрите документацию Babel для получения дополнительной информации.
**Добавление отдельной конфигурации для Babel только на время запуска Jest**
Jest автоматически установит для process.env.NODE_ENV значение 'test' если не указано другое. Вы можете использовать эту опцию, чтобы добавить настройки, которые будут использоваться только во время запуска Jest, например:
Примечание: babel-jest автоматически устанавливается при установке Jest и преобразует файлы если в вашем проекте есть существующая конфигурация babel. Для обхода данного поведения, вы можете явно сбросить опцию transform в конфигурации:
**Поддержка Babel 6**
В 24-й версии Jest прекратил поддерживать Babel 6. Мы настоятельно рекомендуем вам обновиться до Babel 7, который активно поддерживается. Однако, если вы не можете перейти на Babel 7, то либо используйте Jest 23, либо обновитесь до Jest 24 вручную заблокировав babel-jest на 23-й версии, как показано ниже:
Хотя мы обычно рекомендуем использовать одну и ту же версию каждого пакета Jest, данное решение позволит вам продолжить использовать последнюю версию Jest с Babel 6.
С использованием Webpack#
Jest может использоваться в проектах, использующих webpack для управления ресурсами, стилями и компиляцией. Webpack действительно привносит некоторые особенности, способные создать проблемы программистам, в сравнении с другими инструментами. Обратитесь к разделу руководство по работе с Webpack для начала работы с ним.
С использованием Parcel#
Jest может использоваться в проектах, использующих parcel-bundler для управления изображениями, стилями и компиляцией аналогично webpack Parcel не требует настройки Обратитесь к официальной документации.
С использованием TypeScript#
Jest поддерживает TypeScript, через Babel. Сначала убедитесь, что вы следовали инструкциям по настройке Babel выше. Далее установите @babel/preset-typescript через yarn:
Затем добавьте @babel/preset-typescript в список пресетов в ваш babel.config.js.
Однако, есть несколько подводных камней в использовании TypeScript вместе с Babel. Поскольку TypeScript поддерживается в Babel через транспиляцию, Jest не будет проверять типы ваших тестах когда они запущены. Если вы хотите, то вы можете использовать ts-jest взамен, или просто запустите компилятор TypeScript tsc отдельно (или как часть вашего процесса сборки).
Вы также можете установить модуль @types/jest для версии Jest которую вы используете. Это поможет обеспечить полный набор текста при написании ваших тестов с TypeScript.
Для модулей @types/* рекомендуется сопоставлять версию Jest с версией связанного модуля. Например, если вы используете 26.4.0 версию jest , то использование 26.4.x из @types/jest является идеальным. В целом, старайтесь максимально приблизить основную (26) и минорную (4) версию.
 Указание зависимостей и devDependencies в файле package.json 
 Чтобы указать пакеты, от которых зависит ваш проект, вы должны
 перечислите их как  "dependencies"  или  "devDependencies"  в файле  package.json  вашего пакета. Когда вы (или другой пользователь) запускаете  npm install , npm загрузит зависимости и devDependencies, перечисленные в  package.json , которые соответствуют требованиям семантической версии, перечисленным для каждого из них. Чтобы узнать, какие версии пакета будут установлены, используйте калькулятор semver.
  «зависимости» : Пакеты, необходимые вашему приложению в производстве.
  "devDependencies" : Пакеты, необходимые только для локальной разработки и тестирования.
 Добавление зависимостей в файл 
 package.json 
 Вы можете добавить зависимости в файл  package.json  из командной строки или вручную отредактировав файл  package.json .
 Добавление зависимостей в пакет 
.json  из командной строки
 Чтобы добавить зависимости и devDependencies в файл  package.json  из командной строки, вы можете установить их в корневой каталог вашего пакета с помощью флага  --save-prod  для зависимостей (поведение по умолчанию  npm install ) или флаг  --save-dev  для devDependencies.
 Чтобы добавить запись в атрибут  "dependencies"  файла  package.json , в командной строке выполните следующую команду:
  npm install  [--save-prod] 
 
 Чтобы добавить запись в атрибут  "devDependencies"  пакета .json , в командной строке выполните следующую команду:
  npm install  --save-dev 
 
 Ручное редактирование файла 
 package.json 
 Чтобы добавить зависимости в пакет  .json  файл, в текстовом редакторе добавьте атрибут с именем  "dependencies" , который ссылается на имя и семантическую версию каждой зависимости:
  {
  "name": "my_package", 
  "version": «1.0.3.1.0 ". 
 " another_dev_dep ":" 1.0.0 - 1.2.0 "
 } 
 
 npm-install | npm Docs 
 Краткое описание 
  npm install (без аргументов, в каталоге пакета) 
  npm install [<@scope> /]  
  npm install [<@scope> /]  @  
  npm install [<@scope> /]  @  
  npm install [<@scope> /]  @  
  npm install  @npm:  
  npm install :  /  
  npm install  
  npm install  
  npm install  
  npm install  
  псевдонимы: npm i, npm add 
  общие параметры: [- P | --save-prod | -D | --save-dev | -O | --save-optional] [-E | --save-точный] [-B | --save-bundle] [--no -save] [--dry-run] 
 
 Описание 
 Эта команда устанавливает пакет и все пакеты, от которых он зависит.Если
 в пакете есть файл package-lock или shrinkwrap, установка зависимостей
 будет управляться этим, причем  npm-shrinkwrap.json  будет иметь приоритет, если оба
 файлы существуют. См. Package-lock.json и  npm shrinkwrap .
 Пакет  :
 a) папка, содержащая программу, описанную файлом  package.json 
 b) архивный архив с gzip, содержащий (a)
 c) URL-адрес, который разрешается в (b)
 d)   @  , который опубликован в реестре (см. Реестр  ) с (c)
 e)   @   (см.  npm dist- тег ), который указывает на (d)
 f)   , имеющий «последний» тег, удовлетворяющий (e)
 g)   , который разрешается в (a)
 Даже если вы никогда не опубликуете свой пакет, вы все равно можете получить много
 преимущества использования npm, если вы просто хотите написать программу узла (а), и
 возможно, если вы также хотите легко установить его в другом месте
 после упаковки в архив (б).
  npm install  (в каталоге пакета, без аргументов):
 Установите зависимости в локальную папку node_modules.
 В глобальном режиме (т.е. с добавлением  -g  или  --global  к команде),
 он устанавливает текущий контекст пакета (т. е. текущую рабочую
 каталог) как глобальный пакет.
 По умолчанию  npm install  установит все модули, указанные как зависимости
 в пакете . json .
 С флагом  --production  (или когда переменная среды  NODE_ENV 
 установлено значение  production ), npm не будет устанавливать модули, перечисленные в
  devDependencies . Для установки всех модулей, перечисленных в обеих  зависимостях 
 и  devDependencies , когда для переменной среды  NODE_ENV  установлено значение  production ,
 вы можете использовать  --production = false .
 ПРИМЕЧАНИЕ. Флаг  --production  не имеет особого значения при добавлении
 зависимость от проекта.
  npm install  :
 Установите пакет в каталог как символическую ссылку в текущем проекте.
 Его зависимости будут установлены до связывания. Если  <папка>  сидит
 внутри корня вашего проекта его зависимости могут быть перенесены в
 toplevel  node_modules , как и для других типов зависимостей.
  npm install  :
 Установить пакет, который находится в файловой системе.Примечание: если вы просто хотите
 чтобы связать каталог dev с вашим корнем npm, вы можете сделать это проще,
 используя ссылку  npm .
 Требования к тарболу:
 Имя файла  должно  использовать  .tar ,  .tar.gz  или  .tgz  как
 расширение.
 Содержимое пакета должно находиться в подпапке внутри тарбола (обычно она называется  package / ). npm удаляет один уровень каталогов при установке пакета (выполняется эквивалент  tar x --strip-components = 1 ).
 Пакет должен содержать файл  package.json  со свойствами  name  и  version .
 Пример:
  npm install ./package.tgz 
 
  npm install  :
 Получите URL-адрес архива и затем установите его. Чтобы различать
 в этом и других вариантах аргумент должен начинаться с «http: //» или «https: //»
 Пример:
  npm install https: // github.com / indexzero / forever / tarball / v0.5.6 
 
  npm install [<@scope> /]  :
 Выполните   @   install, где    - это конфиг "тега". (Видеть
  конфигурация . Значение конфигурации по умолчанию: , последнее .)
 В большинстве случаев это установит версию модулей, помеченных как
  последний  в реестре npm.
 Пример:
  npm install  @npm:  :
 Установите пакет под настраиваемым псевдонимом.Позволяет использовать несколько версий
 одноименный пакет рядом, более удобные имена импорта для
 пакеты с длинными в противном случае и с заменой вилок git
 или разветвленные пакеты npm в качестве замены. Псевдоним работает только на вашем
 project и не переименовывает пакеты в транзитивных зависимостях.
 Псевдонимы должны соответствовать соглашениям об именах, указанным в
  валидат-npm-имя-пакета .
 Примеры:
  npm install my-react @ npm: react 
  npm install jquery2 @ npm: jquery @ 2 
  npm install jquery3 @ npm: jquery @ 3 
  npm install npa @ npm: npm-package- arg 
 
  `npm install` по умолчанию сохраняет все указанные пакеты в` dependencies`.
  Кроме того, вы можете контролировать, где и как они сохраняются, с помощью дополнительных флагов 
 : 
  * `-P, --save-prod`: пакет появится в ваших` зависимостях`. Это значение по умолчанию 
 , если не указаны «-D» или «-O». 
  * `-D, --save-dev`: Пакет появится в вашем devDependencies. 
  * `-O, --save-optional`: Пакет появится в ваших` optionalDependencies`. 
  * `--no-save`: предотвращает сохранение в` dependencies`.
  При использовании любой из вышеперечисленных опций для сохранения зависимостей в вашем 
  package.json, есть два дополнительных необязательных флага: 
  * `-E, --save-точный`: сохраненные зависимости будут сконфигурированы с 
 , а не с использованием оператора npm по умолчанию semver range 
 . 
  * `-B, --save-bundle`: Сохраненные зависимости также будут добавлены в ваш список` bundleDependencies`. 
  Кроме того, если у вас есть файл `npm-shrinkwrap.json` или` package-lock.json`, то он 
  тоже будет обновлен. 
  <область> не является обязательным. Пакет будет загружен из реестра 
 , связанного с указанной областью. Если реестр не связан с 
  данной области, предполагается реестр по умолчанию. См. [`Scope`] (/ cli / v6 / using-npm / scope). 
  Примечание: если вы не включите символ @ в имя области, npm вместо этого будет интерпретировать 
  как репозиторий GitHub, см. Ниже. Имена областей видимости 
  также должны сопровождаться косой чертой.
  Примеры: 
  `` bash 
  npm install sax 
  npm install githubname / reponame 
  npm install @ myorg / privatepackage 
  npm install node-tap --save-dev 
  npm install dtrace-provider - -save-optional 
  npm install readable-stream --save-точный 
  npm install ansi-regex --save-bundle 
  `` 
  ** Примечание **: если есть файл или папка с именем `  `в текущем рабочем каталоге 
 , затем он попытается установить его, и только 
  попытается получить пакет по имени, если он недействителен.
 
  npm install [<@scope> /]  @  :
 Установите версию пакета, на которую указывает указанный тег.
 Если тег не существует в данных реестра для этого пакета, то этот
 не удастся.
 Пример:
  npm install sax @ latest 
  npm install @ myorg / mypackage @ latest 
 
  npm install [<@scope> /]  @  :
 Установите указанная версия пакета.Это не удастся, если
 версия не была опубликована в реестре.
 Пример:
  npm install [email protected] 
  npm install @ myorg / privatepackage @ 1.5.0 
 
  npm install [<@scope> /]  @ <диапазон версий>  :
 Установить версию пакета, соответствующую указанному диапазону версий. Этот
 будет следовать тем же правилам для разрешения зависимостей, которые описаны в  package.json .
 Обратите внимание, что большинство диапазонов версий следует заключать в кавычки, чтобы ваша оболочка
 относитесь к этому как к единственному аргументу.
 Пример:
  npm install sax @ "> = 0.1.0 <0.2.0" 
  npm install @ myorg / privatepackage @ "> = 0.1.0 <0.2.0" 
 
  npm install  :
 Устанавливает пакет из размещенного поставщика git, клонируя его с помощью  git .
 Для полного удаленного URL-адреса git будет использоваться только этот URL-адрес.
  <протокол>: // [<пользователь> [: <пароль>] @] <имя хоста> [: <порт>] [:] [/] <путь> [
 
  <протокол>  - один из  git ,  git + ssh ,  git + http ,  git + https  или
  git + файл .
 Если задано  #  , оно будет использоваться для клонирования именно этого
 совершить. Если фиксация имеет формат  #semver:  ,    может
 быть любым допустимым диапазоном semver или точной версией, а npm будет искать любые теги
 или ссылки, соответствующие этому диапазону в удаленном репозитории, так же, как это было бы для
 зависимость от реестра. Если ни  #  , ни  #semver:   не являются
 указано, то используется ветвь репозитория по умолчанию.
 Если в репозитории используются подмодули, эти подмодули будут клонированы.
 также.
 Если устанавливаемый пакет содержит сценарий  prepare , его
  зависимости  и  devDependencies  будут установлены, и подготовить
 сценарий будет запущен перед упаковкой и установкой пакета.
 Следующие переменные среды git распознаются npm и будут
 добавлено в среду при запуске git:
  npm install  /  [# ] :
  npm install github:  /  [# ] :
 Установите пакет по адресу  https: // github.com / githubname / githubrepo , автор:
 пытаюсь клонировать его с помощью  git .
 Если задано  #  , оно будет использоваться для клонирования именно этого
 совершить. Если фиксация имеет формат  #semver:  ,    может
 быть любым допустимым диапазоном semver или точной версией, а npm будет искать любые теги
 или ссылки, соответствующие этому диапазону в удаленном репозитории, так же, как это было бы для
 зависимость от реестра. Если ни  #  , ни  #semver:   не являются
 указано, то используется  master .
 Как и в случае с обычными зависимостями git, зависимости   и  devDependencies  будут
 быть установленным, если в пакете есть сценарий подготовки   до того, как пакет будет
 установка сделана.
 Примеры:
  npm install mygithubuser / myproject 
  npm install github: mygithubuser / myproject 
 
  npm install gist: [ /]  [#  | #semver : ] :
 Установите пакет по адресу  https: // gist.github.com/gistID , пытаясь
 клонируйте его с помощью  git . Имя пользователя GitHub, связанное с сутью:
 необязательный и не будет сохранен в  package.json .
 Как и в случае с обычными зависимостями git, зависимости   и  devDependencies  будут
 быть установленным, если в пакете есть сценарий подготовки   до того, как пакет будет
 установка сделана.
 Пример:
  npm install gist: 101a11beef 
 
  npm install bitbucket:  /  [# ] :
 Установите пакет по адресу  https: // битбакет.org / bitbucketname / bitbucketrepo 
 попытавшись клонировать его с помощью  git .
 Если задано  #  , оно будет использоваться для клонирования именно этого
 совершить. Если фиксация имеет формат  #semver:  ,    может
 быть любым допустимым диапазоном semver или точной версией, а npm будет искать любые теги
 или ссылки, соответствующие этому диапазону в удаленном репозитории, так же, как это было бы для
 зависимость от реестра. Если ни  #  , ни  #semver:   не являются
 указано, то используется  master .
 Как и в случае с обычными зависимостями git, зависимости   и  devDependencies  будут
 быть установленным, если в пакете есть сценарий подготовки   до того, как пакет будет
 установка сделана.
 Пример:
  npm install bitbucket: mybitbucketuser / myproject 
 
  npm install gitlab:  /  [# ] :
 Установите пакет по адресу  https //gitlab.com/gitlabname/gitlabrepo 
 попытавшись клонировать его с помощью  git .
 Если задано  #  , оно будет использоваться для клонирования именно этого
 совершить. Если фиксация имеет формат  #semver:  ,    может
 быть любым допустимым диапазоном semver или точной версией, а npm будет искать любые теги
 или ссылки, соответствующие этому диапазону в удаленном репозитории, так же, как это было бы для
 зависимость от реестра. Если ни  #  , ни  #semver:   не являются
 указано, то используется  master .
 Как и в случае с обычными зависимостями git, зависимости   и  devDependencies  будут
 быть установленным, если в пакете есть сценарий подготовки   до того, как пакет будет
 установка сделана.
 Пример:
  npm install gitlab: mygitlabuser / myproject 
  npm install gitlab: myusr / myproj 
 
 Вы можете комбинировать несколько аргументов и даже несколько типов аргументов.
 Например:
  npm install sax @ "> = 0.1.0 <0.2.0 "Руководитель лаборатории 
 
 Аргумент  --tag  будет применяться ко всем указанным целям установки. Если
 тег с заданным именем существует, версия с тегами предпочтительнее более новой
 версии.
 Аргумент  --dry-run  будет сообщать обычным способом, что установка будет
 сделали, фактически ничего не устанавливая.
 Аргумент  --package-lock-only  обновит только  package-lock.json ,
 вместо проверки  node_modules  и загрузки зависимостей.
 Аргумент  -f  или  --force  заставит npm извлекать удаленные ресурсы, даже если
 локальная копия существует на диске.
 Аргумент  --no-fund  скроет сообщение, отображаемое в конце каждого
 install, который подтверждает количество зависимостей, ищущих финансирование.
 См.  npm-fund (1) 
 Аргумент  -g  или  --global  заставит npm установить пакет глобально
 а не локально. Смотрите папки.
 Аргумент  --global-style  заставит npm установить пакет в
 ваша локальная папка  node_modules  с тем же макетом, что и
 global  node_modules  папка. Только ваши прямые зависимости будут отображаться в
  node_modules , и все, от чего они зависят, будет сглажено в их
  node_modules  папок. Это, очевидно, устранит некоторую дедупликацию.
 Аргумент  --ignore-scripts  заставит npm не выполнять никаких
 сценарии, определенные в пакете.json. См. Сценарии  .
 Аргумент  --legacy-bundling  заставит npm установить пакет, например
 что версии npm до 1.4, например, включенная в узел 0.8,
 можно установить пакет. Это устраняет всякую автоматическую дедупликацию.
 Аргумент  --link  заставит npm связывать глобальные установки с
 локальное пространство в некоторых случаях.
 Аргумент  --no-bin-links  не позволит npm создавать символические ссылки для
 любые двоичные файлы, которые может содержать пакет.
 Аргумент  --no-optional  предотвратит необязательные зависимости от
 устанавливается.
 Аргумент  --no-shrinkwrap , который игнорирует доступный
 package lock или shrinkwrap и используйте вместо него package.json.
 Аргумент  --no-package-lock  не позволит npm создать
  package-lock.json  файл. При работе с отключенной блокировкой пакетов npm
 не будет автоматически сокращать ваши модули узлов при установке.
 Аргумент  --nodedir = / path / to / node / source  позволит npm найти
 исходный код node, чтобы npm мог компилировать собственные модули.
 Аргумент  --only = {prod [uction] | dev [elopment]}  вызовет либо только
  devDependencies  или только не  devDependencies , которые должны быть установлены независимо от  NODE_ENV .
 Аргумент  --no-audit  может использоваться для отключения отправки отчетов аудита на
 настроенные реестры.См.  npm-audit  для получения подробной информации о том, что отправляется.
 См. Конфигурацию  . Многие параметры конфигурации имеют некоторые
 влияет на установку, поскольку это большая часть того, что делает npm.
 Алгоритм 
 Для установки пакета npm использует следующий алгоритм:
  загрузить существующее дерево node_modules с диска 
  клонировать дерево 
  получить package.json и отсортированные метаданные и добавить его в клон 
  walk клонировать и добавить любые недостающие зависимости 
  зависимости будут добавлены как можно ближе к верху, насколько это возможно 
  без нарушения каких-либо других модулей 
  сравните исходное дерево с клонированным деревом и составьте список из 
  действий, которые необходимо предпринять для преобразования один к другому 
  выполнить все действия, самые глубокие первые 
  виды действий - установка, обновление, удаление и перемещение 
 
 Для этого пакета  {dep} структура :  A {B, C}, B { C}, C {D} ,
 этот алгоритм дает:
 То есть зависимость от B до C удовлетворяется тем фактом, что A
 уже привел к установке C на более высоком уровне.D все еще установлен
 на верхнем уровне, потому что с ним ничего не противоречит.
 Для  A {B, C}, B {C, D @ 1}, C {D @ 2}  этот алгоритм дает:
  A 
  + - B 
  + - C 
  `- D @ 2 
  + - D @ 1 
 
 Поскольку D @ 1 B будет установлен на верхнем уровне, C теперь должен установить D @ 2
 в частном порядке для себя. Этот алгоритм детерминирован, но разные деревья могут
 производиться, если две зависимости запрашиваются для установки в другой
 заказывать.
 См. Папки для более подробного описания конкретных структур папок, создаваемых npm.
 Ограничения алгоритма установки npm 
 npm откажется устанавливать любой пакет с именем, идентичным
 данный пакет. Это можно изменить с помощью флага  --force , но в
 в большинстве случаев можно просто решить, изменив имя локального пакета.
 Есть несколько очень редких и крайних патологических случаев, когда цикл может
 заставить npm попытаться установить бесконечное дерево пакетов.Вот
 самый простой случай:
  A -> B -> A '-> B' -> A -> B -> A '-> B' -> A -> ... 
 
 где  A  - это какое-то версия пакета, а  A ' - другая версия
 того же пакета. Поскольку  B  зависит от другой версии  A 
 чем тот, что уже есть в дереве, необходимо установить отдельный
 копировать. То же самое верно и для  A ', который должен установить  B' . Потому что  B '
 зависит от исходной версии  A , которая была заменена,
 цикл впадает в бесконечный регресс.
 Чтобы избежать этой ситуации, npm категорически отказывается устанавливать какие-либо
  name @ version , который уже присутствует где-нибудь в дереве пакетов
 папка предков. Более правильным, но более сложным решением было бы
 для символической ссылки существующей версии на новое место. Если это когда-нибудь
 влияет на реальный вариант использования, он будет исследован.
 См. Также 
 node.js - В чем разница между --save и --save-dev в npm install? 
  зависимостей  - это модули, от которых зависит ваш проект,  devDependencies  - это модули, которые вы используете для разработки своего проекта.Подробное описание вы можете прочитать на сайте npmjs:
 Если кто-то планирует загрузить и использовать ваш модуль в своих
 программа, то они, вероятно, не хотят или не нуждаются в загрузке и сборке
 используемая вами внешняя среда тестирования или документации.
 В этом случае лучше всего отобразить эти дополнительные элементы в
 объект devDependencies.
 Примеры зависимостей:  запрос ,  concat-stream , объект .назначьте ,  через 3 .
 Примеры devDependencies:  mocha ,  tape ,  eslint ,  grunt ,  browserify .
 зависимостей всегда устанавливаются всякий раз, когда ваш проект устанавливается или инициализируется, они необходимы для работы вашего проекта. devDependencies предназначены только для разработки (среда тестирования, средство выполнения задач…), и они устанавливаются только тогда, когда кто-то запускает  npm install  из корня проекта.Например, после клонирования репозитория проекта.
 Это легко проверить. Предположим, у меня есть модули  foo ,  bar ,  baz  и  quux  в одном каталоге. Пусть  foo  будет зависимостью от  baz ,  bar  будет devDependency от  baz , а  baz  будет зависимостью от  quux .
  # / $ cd baz
# / baz $ cat package.json
{
  "имя": "баз",
  "версия": "0.0.0 ",
  "dependencies": {
    "foo": "../foo"
  },
  "devDependencies": {
    "bar": "../bar"
  }
}
# / baz $ npm install
[email protected] / tmp / tmpdir / g6jBr9 / baz
├── [email protected]
└── [email protected]
  
 Как видите, установлены и зависимости, и devDependencies.
 Теперь давайте установим  baz  как зависимость от  quux :
  # / $ cd quux
# / quux $ cat package.json
{
  "name": "quux",
  "версия": "0.0.0",
  "dependencies": {
    "baz": "../baz"
  }
}
# / quux $ npm install
# / quux $ npm ls
quux @ 0.0.0 / tmp / tmpdir / g6jBr9 / quux
└─┬ [email protected]
  └── [email protected]
  
 Обратите внимание, что  foo  установлен, а  bar  - нет. Это связано с тем, что если вам требуется какой-то модуль в качестве зависимости от другого модуля (то есть вы являетесь потребителем   этого модуля), вам не нужны его devDependencies, потому что они не нужны для работы модуля.
 node.js - В чем разница между --dev, --save и --save-dev для npm? 
 Во многих интернет-ответах, найденных на различных форумах и во многих документах по установке компонентов через npm, упоминается  --save .
 Что ж, оказывается, что если вы НЕ используете флаг -g, вы получаете --save по умолчанию (теперь это  --save-prod  или  -P  для краткости). Итак, все следующие значения одинаковы:
  нпм и блабла
npm установить blabla
npm i blabla - сохранить
npm установить blabla
npm i blabla --save-prod
npm установить blabla -P
  
 Эта команда выполняет две функции.
 Устанавливает пакет  blabla  и все его зависимости, если они отсутствуют или нуждаются в обновлении.Место установки находится в вашем проекте в папке  node modules .
 Он отмечает этот пакет в package.json в разделе  dependencies . Поэтому в следующий раз, когда вы выполните  npm install  или  yarn install , все правильные пакеты будут установлены в соответствии с этим списком.
 Ожидается, что глобальные пакеты будут установлены в папке  node_modules вашего пользователя  для глобальных пакетов. Установленные вами глобальные пакеты не указаны в вашем проекте.См. Следующий раздел.
 Следующие элементы эквивалентны друг другу, но на этот раз они НЕ записывают свои действия в файл package.json, а работают, потому что находятся «в пути»:
  нпм и -g блабла
npm я blabla -g
npm i blabla --save-global
  
 В приведенной выше строке установите  blabla  и все его зависимости, если они отсутствуют или нуждаются в обновлении, но ничего не записывайте в файл  package.json .
 Последним, но не менее важным является вариант  dev .Все следующие эквиваленты
  нпм i -d blabla
npm я blabla -d
npm установить blabla --save-dev
npm установить blabla --d
  
 Это делает следующее:
 Он устанавливает blabla и все зависимости в папку в вашем проекте под названием  node modules . и
 В нем перечислены пакет  blabla  и любые другие пакеты, которые нужны blabla, внутри package.json , но на этот раз  в специальном разделе Dev-Dependencies.
 Затем вы можете запустить  npm i  (или  yarn i ), и теперь это зависит. Если вы упаковываете как разработчик, все устанавливается как обычно. (нечего писать в  project.json , потому что мы просто читаем все точно из списка именно в этом файле !!)
 Но, если вы устанавливаете для производства (не входит в объем этого ответа, как это сделать), все пакеты Dev не будут установлены. Это были вещи, которые вам нужны только на стадии разработки, например линтеры, которые читают и проверяют ваш код на наличие ошибок.
 В чем разница между -save и -save-dev в Node.js? 
 В чем разница между –save и –save-dev в Node.js?
 NPM (Node Project Manager) - это менеджер пакетов, используемый средой выполнения JavaScript Node.js. В нем есть две очень часто используемые команды для загрузки различных зависимостей:  npm install --save [имя-пакета]  и  npm install --save-dev [имя-пакета] . Обе команды приведут к загрузке и установке пакетов с серверов NPM, но у них несколько разные способы.
  npm install [имя-пакета] –save : Когда –save используется без -dev, это означает, что пакет зависит от ядра. Основная зависимость - это любой пакет, без которого приложение не может выполнять предполагаемую работу. В файле package.json в разделе зависимостей содержится список основных зависимостей. Установка npm также приведет к аналогичному результату. Когда кто-то устанавливает ваш пакет, он также установит все пакеты, перечисленные в разделе зависимостей пакета.json. Пример: экспресс, body-parser.
  npm install [имя-пакета] –save-dev : Когда –save-dev используется с npm install, это означает, что пакет является зависимостью разработки. Зависимость разработки - это любой пакет, отсутствие которого не повлияет на работу приложения. В файле package.json в разделе devDependencies содержится список всех зависимостей разработки. Когда кто-то устанавливает ваш пакет, он не будет устанавливать никаких зависимостей разработки, но если они клонируют репозиторий, они также установят все зависимости разработки.Пример: nodemon
 –save  –save-dev
 Установленный пакет зависит от ядра.  Установленный пакет не является основным, а зависит от разработки.
 Все основные зависимости перечислены в разделе зависимости в package.json.  Все зависимости разработки перечислены в разделе devDependencies в package.json.
 Он будет установлен, если третье лицо попытается установить или клонировать ваш пакет.  Он будет установлен, если третье лицо попытается клонировать ваш пакет.
 Пример: express, body-parser и т. Д.  Пример: nodemon
 Что означает -save для установки NPM? 
 Что означает –save для установки NPM?
  NPM (Node Package Manager)  - это менеджер пакетов по умолчанию, используемый в среде выполнения JavaScript в Node.js. Он имеет очень часто используемую команду  npm install [Package Name] –save .Но на самом деле нет никакой разницы между  npm install [Package Name]  и  npm install [Package Name] - сохраните  в более поздней версии после npm 5.0.0 и новее.
 До npm 5.0.0 необходимо было добавить  --save  после имени пакета, поскольку он сохранит установленный пакет в файле package.json в разделе зависимостей. Если вы используете последнюю версию npm, избавьтесь от ненужного ввода и используйте  npm install [Package Name]  вместо  npm install [Package Name]  --save   по умолчанию он добавит установленный пакет в зависимость список в пакете.json файл.
  NPM имеет несколько команд, которые перечислены ниже: 
  –save или -S:  Когда следующая команда используется с npm install, это сохранит все установленные вами основные пакеты в разделе зависимостей в package.json файл. Основные зависимости - это те пакеты, без которых ваше приложение не даст желаемых результатов. Но, как упоминалось ранее, это ненужная функция в версии npm 5.0.0 и новее. npm install --save 
  –save-prod или -P:  Следующая команда введена в более позднюю версию npm, она будет выполнять ту же задачу, что и команда  --save , если только другая команда, например  -D  или  -O  присутствует. npm install --save-prod 
  –save-dev или -D:  С помощью команды  --save-dev  или  -D  ваши установленные пакеты будут добавлены в раздел devDependency файла package.json . Зависимости разработки - это те пакеты, которые предназначены только для целей разработки и не повлияют на результат приложения. npm install --save-dev 
  –save-optional или -O:  При использовании этой команды устанавливаемые пакеты будут перечислены в необязательном разделе «Зависимости» пакета.json файл. Необязательные зависимости - это те пакеты, которые используются только при использовании определенной функции приложения и не потребуются, если эта функция не используется.  npm install --save-optional  
  –no-save:  Когда эта команда используется с npm install, она не позволит сохранить установленные пакеты в разделе зависимостей. npm install --no-save 
  Примечание.  NPM предоставляет два дополнительных параметра для сохранения зависимостей в пакете.json файл.
  –save-точный или -E:  Это дополнительная или необязательная команда, предоставляемая npm, которая сохранит точную версию установленных пакетов, настроенных во время разработки. Он не будет загружать зависимости от оператора диапазона серверов npm по умолчанию. npm install --save-exact 
  –save-bundle или -B:  Следующая команда также является необязательной при использовании  --save-bundle  или  -B .Это также добавит сохраненные зависимости в список bundleDependency. npm install --save-bundle 
 Переход с npm | Пряжа 
 Переход с npm должен быть довольно простым процессом для большинства пользователей. Пряжа может
 использовать тот же формат  package.json , что и npm, и может установить любой пакет из
 реестр npm.
 Если вы хотите попробовать Yarn в существующем проекте npm, просто попробуйте запустить:
 Это разместит вашу папку  node_modules  с использованием алгоритма разрешения Yarn.
 это совместимо с
 узел.js алгоритм разрешения модуля.
 Если вы получили сообщение об ошибке, проверьте, нет ли существующей проблемы, или сообщите об этом в
 Система отслеживания проблем с пряжей.
 Когда вы запускаете  yarn  или  yarn add  , Yarn сгенерирует файл  yarn.lock  в корневом каталоге вашего пакета. Вам не нужно читать или понимать этот файл - просто зарегистрируйте его в системе контроля версий. Когда другие люди начнут использовать Yarn вместо  npm , файл  yarn.lock  гарантирует, что они получат точно такие же зависимости, как и вы.
 В большинстве случаев пряжа  с пряжей  или  с добавлением  в первый раз будет работать. В некоторых случаях информация в файле  package.json  недостаточно явна, чтобы устранить зависимости, и детерминированный способ, которым Yarn выбирает зависимости, приведет к конфликтам зависимостей. Это особенно вероятно в больших проектах, где иногда  npm install  не работает, и разработчики часто удаляют  node_modules  и перестраивают с нуля.Если это произойдет, попробуйте использовать  npm , чтобы сделать версии зависимостей более явными, перед преобразованием в Yarn.
 Начиная с Yarn 1.7.0, вы можете импортировать свое состояние package-lock.json, сгенерированное  npm , в Yarn, используя  yarn import .
 Другие разработчики проекта могут продолжать использовать  npm , поэтому вам не нужно заставлять всех участников вашего проекта выполнять конвертацию одновременно. Все разработчики, использующие  пряжи , получат точно такую же конфигурацию, как и разработчики, использующие  пряжи , могут получить немного разные конфигурации, что является предполагаемым поведением  пряжи .
 Позже, если вы решите, что Yarn не для вас, вы можете просто вернуться к использованию  npm  без каких-либо особых изменений. Вы можете удалить свой старый файл  yarn.lock , если никто в проекте больше не использует Yarn, но в этом нет необходимости.
 Если вы сейчас используете файл  npm-shrinkwrap.json , имейте в виду, что вы можете
 в конечном итоге получится другой набор зависимостей. Пряжа не поддерживает npm
 сжатые файлы, поскольку в них недостаточно информации для работы Yarn
 более детерминированный алгоритм.Если вы используете термоусадочный файл, это может быть проще
 конвертировать всех, кто работает над проектом, на использование Yarn одновременно. Просто удалите
 существующий файл  npm-shrinkwrap.json  и зарегистрируйте вновь созданный файл  yarn.lock .
 Сравнение команд CLI 
 нпм (v5)  Пряжа
  npm установить   пряжа прибавить 
   (нет данных)    добавочная пряжа - плоская 
   (нет данных)    добавление пряжи --har 
  npm install --no-package-lock   добавление пряжи --no-lockfile 
   (нет данных)    добавление пряжи --pure-lockfile 
  npm install [package] --save   пряжа добавить [упаковка] 
  npm install [пакет] --save-dev   пряжа добавить [пакет] --dev 
   (нет данных)    пряжа добавить [упаковка] --peer 
  npm install [package] --save-optional   пряжа добавить [упаковка] - опционально 
  npm install [пакет] --save-exact   пряжа добавить [упаковка] --exact 
   (нет данных)    пряжа добавить [пакет] --tilde 
  npm install [пакет] --global   пряжа global add [упаковка] 
  обновление npm --global   пряжа global upgrade 
  Восстановление npm   пряжа add -force 
  удаление npm [пакет]   удаление пряжи [упаковка] 
  Чистка кэша npm   чистка пряжи [упаковка] 
  rm -rf node_modules && npm install   Модернизация пряжи 
  Основная версия npm   вариант пряжи - основной 
  минорная версия npm   вариант пряжи - минор 
  патч версии npm   вариант пряжи - нашивка 
.
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя * 
Email * 
Сайт 
  
Навигация по записям
Previous PostОсенние букеты обои для рабочего стола: Осенний букет — Скачать обои на рабочий стол в один клик!
Next PostКартинку в вектор онлайн: Он-лайн конвертирование в формат SVG

нпм (v5)	Пряжа
`npm установить`	`пряжа прибавить`
*(нет данных)*	`добавочная пряжа - плоская`
*(нет данных)*	`добавление пряжи --har`
`npm install --no-package-lock`	`добавление пряжи --no-lockfile`
*(нет данных)*	`добавление пряжи --pure-lockfile`
`npm install [package] --save`	`пряжа добавить [упаковка]`
`npm install [пакет] --save-dev`	`пряжа добавить [пакет] --dev`
*(нет данных)*	`пряжа добавить [упаковка] --peer`
`npm install [package] --save-optional`	`пряжа добавить [упаковка] - опционально`
`npm install [пакет] --save-exact`	`пряжа добавить [упаковка] --exact`
*(нет данных)*	`пряжа добавить [пакет] --tilde`
`npm install [пакет] --global`	`пряжа global add [упаковка]`
`обновление npm --global`	`пряжа global upgrade`
`Восстановление npm`	`пряжа add -force`
`удаление npm [пакет]`	`удаление пряжи [упаковка]`
`Чистка кэша npm`	`чистка пряжи [упаковка]`
`rm -rf node_modules && npm install`	`Модернизация пряжи`
`Основная версия npm`	`вариант пряжи - основной`
`минорная версия npm`	`вариант пряжи - минор`
`патч версии npm`	`вариант пряжи - нашивка`

Save dev npm: javascript — В чём отличие npm install —save-dev от —save

frontend — Ошибка npm i gulp-sass —save-dev

Несколько полезностей по работе с NPM / Хабр

Установка пакетов

Какие варианты еще есть?

Сокращенные варианты команд

Подготовка к npm init

А что еще можно настраивать?

Проверить, не устарели ли пакеты

Фиксируем версии пакетов

Обновление версии NPM

Зачем нужен npm —save-dev — CodeRoad

2 ответа

Похожие вопросы:

Разница между npm install —save и npm install —save-dev

3 ответа

Похожие вопросы:

node.js — В чем разница между —save и —save-dev в npm install?

Использование модулей Node.js с npm и package.json

Введение

Предварительные требования

Шаг 1 — Создание файла

Использование команды

Шаг 2 — Установка модулей

Зависимости разработки

Автоматически сгенерированные файлы:

Установка из package.json

Глобальная установка

Шаг 3 — Управление модулями

Указание модулей

Обновление модулей

Удаление модулей

Проверка модулей

Заключение

Начало работы · Jest

Запуск из командной строки#

Дополнительная конфигурация#

Создание базового файла конфигурации#

С использованием Babel#

С использованием Webpack#

С использованием Parcel#

С использованием TypeScript#

Указание зависимостей и devDependencies в файле package.json

Добавление зависимостей в файл

Добавление зависимостей в пакет

Ручное редактирование файла

npm-install | npm Docs

Краткое описание

Описание

Алгоритм

Ограничения алгоритма установки npm

См. Также

node.js - В чем разница между --save и --save-dev в npm install?

node.js - В чем разница между --dev, --save и --save-dev для npm?

В чем разница между -save и -save-dev в Node.js?

Что означает -save для установки NPM?

Переход с npm | Пряжа

Сравнение команд CLI

Добавить комментарий Отменить ответ

`Шаг 2 — Установка модулей`

`Автоматически сгенерированные файлы:`

`Установка из package.json`

`Глобальная установка`

`Шаг 3 — Управление модулями`

`Указание модулей`

`Обновление модулей`

`Удаление модулей`

`Проверка модулей`

`Заключение`

`Начало работы · Jest`

`Запуск из командной строки#`

`Дополнительная конфигурация#`

`Создание базового файла конфигурации#`

`С использованием Babel#`

`С использованием Webpack#`

`С использованием Parcel#`

`С использованием TypeScript#`

`Указание зависимостей и devDependencies в файле package.json`

`Добавление зависимостей в файл`

`Добавление зависимостей в пакет`

`Ручное редактирование файла`

`npm-install | npm Docs`

`Краткое описание`

`Описание`

`Алгоритм`

`Ограничения алгоритма установки npm`

`См. Также`

`node.js - В чем разница между --save и --save-dev в npm install?`

`node.js - В чем разница между --dev, --save и --save-dev для npm?`

`В чем разница между -save и -save-dev в Node.js?`

`Что означает -save для установки NPM?`

`Переход с npm | Пряжа`

`Сравнение команд CLI`

`Добавить комментарий Отменить ответ`