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

Другие материалы

• Для чего использовать дженерики в TypeScript
• Автоматизация вёрстки. npm, package.json
• Как искать и выбирать npm-пакеты?

«Доктайп» — журнал о фронтенде. Читайте, слушайте и учитесь с нами.

ТелеграмПодкастБесплатные учебники

Зависимости для разработки | JS: Настройка окружения

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

У любого проекта есть как минимум два режима использования. Их обычно называют средами. Например, когда разработчик работает над проектом у себя на компьютере, то он запускает его в среде разработки. Когда же проект попадает в то место, где им пользуются, то тогда среду называют продакшеном (production).

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

С точки зрения использования, эти пакеты ничем не отличаются от пакетов, устанавливаемых в dependencies. Разница только в том, где их импортируют. Как правило, для тестирования кода создается отдельная директория, внутри которой находится код тестов, которые запускаются только в среде разработки. Поэтому импорты этого кода не пересекаются с импортами кода самого проекта.

Все это можно своими глазами увидеть в специальном пакете, созданном Хекслетом как пример эталонного проекта.

Флаг --production

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

# Вот теперь зависимости из devDependencies устанавливаться не будут
npm install --production
# Продакшен режим можно задать и с помощью переменной окружения
NODE_ENV=production npm install

Когда же проект собирается для деплоя на сервер (например, через Github Actions), то флаг нужно применять с npm ci:

npm ci --production

Открыть доступ

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

• 130 курсов, 2000+ часов теории
• 1000 практических заданий в браузере
• 360 000 студентов

Электронная почта *

Отправляя форму, вы принимаете «Соглашение об обработке персональных данных» и условия «Оферты», а также соглашаетесь с «Условиями использования»

Наши выпускники работают в компаниях:

нпм-установка | npm Docs

Synopsis

 
   
 
 npm install [ ...] 
 
 псевдонимы: add, i, in, ins, inst, insta, instal, isnt, isnt, isntal, isntall 
 90 011 
 Описание 
  
  Эта команда устанавливает пакет и все пакеты, от которых он зависит. Если
пакет имеет package-lock, или файл npm термоусадочной упаковки, или файл блокировки пряжи,
установка зависимостей будет обусловлена ​​этим, соблюдая
следующий порядок старшинства: 
 
 
  npm-shrinkwrap.json  
 
  package-lock.json  
 
  yarn.lock  
 
 
 См.  package-lock.j сын и
  н/мин термоусадочная пленка  . 
 
 Пакет  : 
 
 
 а) папка, содержащая программу, описанную
  package.json  файл 
 
 b) архив с gzip-архивом, содержащий (a) 
 
 c) URL-адрес, который разрешается в (b) 
 
 d)  <имя>@<версия> публикуется в реестре (см.
  реестр  ) с (c) 
 
 e)  @  (см.  npm dist-tag  ), который
указывает на (d) 
  
 f)   , у которого есть «последний» тег, удовлетворяющий (e) 
 
 g)   , который разрешается в (a) 
 
 
 Даже если вы никогда не публикуйте свой пакет, вы все равно можете получить много преимуществ
использования npm, если вы просто хотите написать программу узла (a), и, возможно, если
вы также хотите иметь возможность легко установить его в другом месте после упаковки
в архив (б). 
 
 
 
  npm install  (в каталоге пакета, без аргументов): 
 
 Установите зависимости в локальную папку  node_modules .  
 
 В глобальном режиме (т. е. с добавлением к команде  -g  или  --global ),
он устанавливает текущий контекст пакета (т. е. текущий рабочий
каталог) как глобальный пакет. 
 
 По умолчанию  npm install  установит все модули, указанные как
зависимости в 
 
  package.json  . 
 
 С флагом  --production  (или когда среда  NODE_ENV 
установлена ​​переменная  production  ), npm не будет устанавливать перечисленные модули
в  devDependencies  . Чтобы установить все модули, перечисленные в обоих
  зависимости  и  devDependencies  когда  NODE_ENV  среда
установлена ​​переменная  production  , вы можете использовать  --production=false  . 
 
 
 ПРИМЕЧАНИЕ:  -- производство 9Флаг 0019 не имеет особого значения при добавлении
зависимость от проекта. 
 
 
 
 
  npm install   : 
 
 Если    находится внутри корня вашего проекта, его зависимости будут установлены и могут
быть подняты на верхний уровень  node_modules , как и для других
виды зависимостей.
  Если  <папка>  находится вне корня вашего проекта,
  npm не будет устанавливать зависимости пакета  в каталоге  <папка>  ,
но он создаст символическую ссылку на    . 
 
 
 ПРИМЕЧАНИЕ. Если вы хотите установить содержимое каталога, например пакет из реестра, вместо создания ссылки, вам необходимо использовать параметр  --install-links . 
 
 
 Пример: 
 
 
   
 
 npm install ../../other-package --install-links 
 
 npm install ./sub-package 
 
 90 005  npm install   :
 Установить пакет, который находится в файловой системе. Примечание: если вы просто
хотите связать каталог dev с вашим корнем npm, вы можете сделать это подробнее
легко, используя ссылку  npm  .
 Требования к архиву:
 Имя файла  должно  использовать  .tar  , 
  .tar.gz  или  . tgz  в качестве
расширение.
 Содержимое пакета должно находиться во вложенной папке внутри архива
(обычно его называют  упаковка/). npm удаляет один слой каталога
при установке пакета (эквивалент  tar x
--strip-components=1  запущен).
 Пакет должен содержать файл  package.json  с именем   и  версии  свойств.
 Пример:
 
   
 
 npm install ./package.tgz 
 
  npm install  900 19 :
 Получите URL-адрес архива, а затем установите его. Для того, чтобы различать
для этого и других параметров аргумент должен начинаться с «http://» или «https://»
 Пример:
 
   
 
 npm install https://github.com/indexzero/forever/tarball/v0.5.6 
  
  npm install [<@scope>/]  :
 Выполните установку  @ , где    — это конфигурация «tag». (Видеть  конфиг  . Значение конфигурации по умолчанию —  последняя .)
 В большинстве случаев это установит версию модулей, помеченных как  последний  в реестре npm.
 Пример:
 
   
 
 npm install sax 
 
  npm install  по умолчанию сохраняет любые указанные пакеты в  зависимостей .
Кроме того, вы можете контролировать, где и как они сохраняются с помощью некоторых
дополнительные флаги:
  -P, --save-prod  : пакет появится в ваших  зависимостях  . Этот
используется по умолчанию, если не присутствуют  -D  или  -O 
 .
  -D, --save-dev  : Пакет появится в ваших  devDependencies  .
  -O, --save-Optional  : Пакет появится в вашем  дополнительные зависимости  .
  --no-save  : Предотвращает сохранение до  зависимостей  .
 При использовании любой из вышеперечисленных опций для сохранения зависимостей в
package.json есть два дополнительных необязательных флага:
  -E, --save-exact  : Сохраненные зависимости будут настроены с
точную версию, а не использовать оператор диапазона semver по умолчанию npm.
  -B, --save-bundle  : Сохраненные зависимости также будут добавлены в ваш  bundleDependencies  список.
 Далее, если у вас есть  npm-shrinkwrap.json  или  package-lock.json  тогда он тоже будет обновляться.
  <область>  является необязательным. Пакет будет загружен из реестра
связанные с указанной областью. Если реестр не связан с
в данной области предполагается реестр по умолчанию. Видеть  объем  .
 Примечание. Если вы не включаете символ @ в имя области действия, npm
вместо этого интерпретируйте это как репозиторий GitHub, см. ниже. Имена областей
также должен сопровождаться косой чертой.
 Примеры:
 
   
 
 npm install sax 
 
 npm install githubname/reponame 
 
 npm install @myorg/privatepackage 
 
 npm install node-tap --save-dev 
 
 npm установить dtrace-provider --save- необязательно 
 
 npm install readable-stream --save-exact 
 
 npm install ansi-regex --save-bundle 
 
  Примечание . Если в текущем
рабочий каталог, то он попытается установить его, и попытается только
получить пакет по имени, если оно недействительно.
  npm install <псевдоним>@npm:<имя>  :
 Установить пакет под пользовательским псевдонимом. Позволяет использовать несколько версий
одноимённый пакет рядом, более удобные имена импорта для
пакеты с другими длинными и с использованием замен git forks
или разветвленные пакеты npm в качестве замены. Псевдоним работает только на вашем
project и не переименовывает пакеты в транзитивных зависимостях.
Псевдонимы должны соответствовать соглашениям об именах, указанным в  проверка имени пакета npm  .
 Примеры:
 
   
 
 npm install my-react@npm:react 
 
 npm install jquery2@npm:jquery@2 
 
 npm install jquery3@npm:jquery@3 90 006 
 npm установить npa@npm:npm- package-arg 
 
  npm install [<@scope>/]@  :
 Установите версию пакета, на который ссылается указанный тег.
Если тег не существует в данных реестра для этого пакета, то этот
не удастся.
 Пример:
 
   
 
 npm install sax@latest 
 
 npm install @myorg/mypackage@latest 
 
  npm install [ <@scope>/]<имя>@<версия>  :
 Установите указанную версию пакета. Это не удастся, если
версия не была опубликована в реестре.
 Пример:
 
   
 
 npm install [email protected] 
 
 npm install @myorg/[email protected] 
 
  npm install [<@scope>/]<имя>@<диапазон версий>  :
 Установите версию пакета, соответствующую указанному диапазону версий. Это будет следовать тем же правилам для разрешения зависимостей, которые описаны в  package.json  .
 Обратите внимание, что большинство диапазонов версий должны быть заключены в кавычки, чтобы ваша оболочка
будет рассматривать его как один аргумент.
 Пример:
 
   
 
 npm install sax@">=0.1.0 <0.2.0" 
 
 npm install @myorg/privatepackage@"16 - 17" 
 
  npm install   :
 Устанавливает пакет из размещенного git-провайдера, клонируя его с помощью  гит  . Для полного удаленного URL-адреса git будет предпринята попытка только этого URL-адреса.
 
   
 
 <протокол>://[<пользователь>[:<пароль>]@]<имя хоста>[:<порт>][:][/]<путь>[# | #semver:] 
 
  <протокол>  является одним из  git  ,  git+ssh  ,  git+http  ,  git+https  или  гит+файл  .
 Если указан  # , он будет использоваться для клонирования именно этого
совершить. Если коммит имеет формат  #semver:  ,    может быть любым допустимым диапазоном semver или точной версией, и npm будет искать
любые теги или ссылки, соответствующие этому диапазону в удаленном репозитории, например
это было бы для зависимости реестра. Если ни  #  или  #semver:  указано, то ветвь по умолчанию
используется репозиторий.
 Если репозиторий использует подмодули, эти подмодули будут
тоже клонировал.
 Если устанавливаемый пакет содержит сценарий подготовки  , его  зависимости  и  devDependencies  будут установлены, и подготовка
script будет запущен до того, как пакет будет упакован и установлен.
 Следующие переменные среды git распознаются npm и будут
быть добавленным в среду при запуске git:
  GIT_ASKPASS 
  GIT_EXEC_PATH 
  GIT_PROXY _COMMAND 
  GIT_SSH 
  GIT_SSH_COMMAND 
 90 018 GIT_SSL_CAINFO 
  GIT_SSL_NO_VERIFY 
 Подробности смотрите на справочной странице git.
 Примеры:
 
   
 
 npm install git+ssh://[email protected]:npm/cli.git#v1.0.27 95.0 
 
 npm install git+https://[email protected]/npm/cli.git 
 
 npm install git://github.com/npm/cli.git#v1.0.27 
 
 GIT_SSH_COMMAND='ssh - i ~/.ssh/custom_ident' npm install git+ssh://[email protected]:npm/cli.git 
 
  npm install /[#] :
  npm install github:/[#] :
 Установите пакет по адресу  https://github.com/githubname/githubrepo  от
попытка клонировать его с помощью  git  .
 Если указан  # , он будет использоваться для клонирования именно этого
совершить. Если коммит имеет формат  #semver:  ,    может быть любым допустимым диапазоном semver или точной версией, и npm будет искать
любые теги или ссылки, соответствующие этому диапазону в удаленном репозитории, например
это было бы для зависимости реестра. Если ни  #  или  #semver:  указано, тогда используется ветвь по умолчанию.
 Как и в случае обычных зависимостей 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:/[#< commit-ish>]  :
 Установите пакет по адресу  https: //bitbucket.org/bitbucketname/bitbucketrepo  пытаясь клонировать его с помощью  git  .
 Если указан  # , он будет использоваться для клонирования именно этого
совершить. Если коммит имеет формат  #semver:  ,    может
быть любым допустимым диапазоном semver или точной версией, и npm будет искать любые теги
или ссылки, соответствующие этому диапазону в удаленном репозитории, как это было бы для
зависимость реестра. Если ни  # , ни  #semver:  не
указано, то используется мастер  .
 Как и в случае с обычными зависимостями git,  зависимостей  и  devDependencies  будут
быть установлен, если пакет имеет  подготовьте сценарий  до того, как пакет
сделал установку.
 Пример:
 
   
 
 npm install bitbucket:mybitbucketuser/myproject 
 
  npm install gitlab:/[#< commit-ish>]  :
 Установить пакет по адресу  https://gitlab.com/gitlabname/gitlabrepo  пытаясь клонировать его с помощью  git  .
 Если указан  # , он будет использоваться для клонирования именно этого
совершить. Если коммит имеет формат  #semver:  ,    может
быть любым допустимым диапазоном semver или точной версией, и npm будет искать любые теги
или ссылки, соответствующие этому диапазону в удаленном репозитории, как это было бы для
зависимость реестра. Если ни  # , ни  #semver:  не
указано, то используется мастер  .
 Как и в случае с обычными зависимостями git,  зависимостей  и  devDependencies  будут
быть установлен, если пакет имеет 95. 0
 

Вы можете комбинировать несколько аргументов и даже несколько типов аргументов. Например:

 
   
 
 npm install sax@">=0.1.0 <0.2.0" Bench супервизор 
 

Аргумент --tag будет применяться ко всем указанным целям установки. Если Тег с данным именем существует, версия с тегом предпочтительнее, чем более новые версии.

Аргумент --dry-run сообщит обычным образом, что обошлось бы без фактической установки чего-либо.

Аргумент --package-lock-only будет обновлять только package-lock.json вместо проверки node_modules и загрузки зависимости.

Аргумент -f или --force заставит npm получать удаленные ресурсы даже если локальная копия существует на диске.

 
   
 
 npm install sax --force 
 

Конфигурация

См. справку config . Многие из конфигураций параметры имеют некоторое влияние на установку, так как это большая часть того, что npm делает.

Вот некоторые из наиболее распространенных вариантов установки.

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

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

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

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

save-exact
• По умолчанию: false
• Тип: Boolean

Зависимости, сохраненные в package.json, будут настроены с точной версией вместо использования оператора диапазона semver по умолчанию npm.

global
• По умолчанию: false
• Тип: Boolean

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

• устанавливаются в папку {prefix}/lib/node_modules вместо текущего рабочего каталога.
• bin-файлы связаны с {prefix}/bin
• man-страницы связаны с {prefix}/share/man
в глобальном стиле
90 017 По умолчанию: false
• Тип: логический

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

устаревшая комплектация
• По умолчанию: false
• Тип: Boolean

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

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

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

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

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

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

strict-peer-deps
• По умолчанию: false
• Тип: логический

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

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

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

package-lock
• По умолчанию: true
• Тип: Boolean

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

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

foreground-scripts
• По умолчанию: false
• Тип: Boolean

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

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

ignore-scripts
• По умолчанию: false
• Тип: Boolean

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

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

аудит
• По умолчанию: true
• Тип: Boolean

реестр по умолчанию и все реестры, настроенные для областей. См. документация на npm аудит для получения подробной информации о том, что поданный.

bin-links
• По умолчанию: true
• Тип: Boolean

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

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

фонд
• По умолчанию: правда
• Тип: Boolean

При значении «true» в конце каждой установки npm отображается сообщение признавая количество зависимостей, ищущих финансирование. См. н/мин фонд для деталей.

пробный запуск
• По умолчанию: false
• Тип: логический

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

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

рабочая область
• По умолчанию:
• Тип: строка (может быть задана несколько раз)

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

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

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

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

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

рабочих областей
• По умолчанию: null
• Тип: null или Boolean

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

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

• Команды, которые работают с деревом node_modules (установка, обновление и т. д.) свяжет рабочие области в 9Папка 0018 node_modules . - Команды, которые делают другие вещи (тестирование, выполнение, публикация и т. д.) будут работать с корневым проектом, , если одна или несколько рабочих областей не указаны в конфигурации рабочей области .

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

include-workspace-root
• По умолчанию: false
• Тип: логический

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

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

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

install-links
• По умолчанию: false
• Тип: Boolean

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

Алгоритм

Учитывая структуру пакета {dep} : A{B,C}, B{C}, C{D} , алгоритм установки npm выдает:

 
   
 
 A 
 
 +-- B 
 
 +-- C 
 
 +-- D 
 

То есть зависимость от B к C удовлетворяется тем фактом, что что А уже заставило C быть установленным на более высоком уровне. D по-прежнему установлен вверху уровень, потому что с ним ничего не конфликтует.

Для A{B,C}, B{C,D@1}, C{D@2} , этот алгоритм выдает:

 
   
 
 A 
 
 +-- B 
 
 +-- C 
 
 `-- D@2 
 
 +-- D@1 
 90 011 
 Поскольку D@1 B будет установлен на верхнем уровне, C теперь должен установить
D@2 лично для себя. Этот алгоритм является детерминированным, но отличается
деревья могут быть созданы, если две зависимости запрашиваются для установки в
другой порядок. 
 
 См. папки для более подробного описания
конкретные структуры папок, которые создает npm.  
  
 См. также 
 
 
 Папки npm 
 
 Обновление npm 
 
 Аудит npm 
 
 Фонд npm 
 
 Ссылка npm 
 
 Перестройка npm 
 
 сценарии npm 
 
 конфигурация npm 
 
 npmrc 
 
 реестр npm 
 
 npm dist-tag 
 
 npm uninstall 
 
 npm shrinkwrap 
 
 package.json 
 
 workspaces 
 
 Редактировать эту страницу на GitHub 
 node.js — В чем разница между --save и --save-dev? 
  

                        спросил
                          9 лет, 1 месяц назад  
 

                        Изменено
                        1 год, 4 месяца назад
 
 

                        Просмотрено
                        450 тысяч раз
 
 
 В чем разница между: 
 
 npm install [package_name]
 
 и:
 npm install [package_name] --save
 
 и:
 npm install [package_name] --save-dev
 
 Что это значит? И каков на самом деле эффект ключевых слов  --save  и  -dev ?
 node. js
 npm
 сохранить
 пакет
 5
 Разница между  --save  и  --save-dev  может быть не сразу заметна, если вы пробовали их оба в своих проектах. Итак, вот несколько примеров...
 Допустим, вы создаете приложение, использующее 91.4.1",
} 

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

Взято непосредственно из документации NPM docs#dependencies

Зависимости

Зависимости указаны в простом объекте, который сопоставляет имя пакета к диапазону версий. Диапазон версий — это строка, содержащая один или больше дескрипторов, разделенных пробелами. Зависимости также могут быть выявлены с tar-архивом или URL-адресом git.

Пожалуйста, не добавляйте тестовые наборы или транспиляторы в свои зависимости объект. См. devDependencies ниже.

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

11

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

11

По умолчанию NPM просто устанавливает пакет в node_modules. Когда вы пытаетесь установить зависимости для своего приложения/модуля, вам нужно сначала установить их, а затем добавить в раздел зависимостей вашего package.json .

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

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

Зависимости Dev — это те зависимости, которые необходимы только для разработки пакета. Это могут быть тестировщики, компиляторы, упаковщики и т. д. Оба типа зависимостей хранятся в папке пакета 9.0018 файл package.json . --save добавляет к зависимостям , --save-dev добавляет к devDependencies

Документацию по установке npm можно найти здесь.

--

Обратите внимание, , что --save теперь является параметром по умолчанию, начиная с NPM 5. Поэтому он больше не нужен явно. Можно запустить npm install без --save для достижения того же результата.

5

Позвольте мне привести пример:

• Вы являетесь разработчиком очень СЕРЬЕЗНОЙ библиотеки npm , которая использует различные библиотеки тестирования для тестирования пакета.
• Пользователи загружают вашу библиотеку и хотят использовать ее в своем коде. Нужно ли им также загружать ваши тестовые библиотеки? Может быть, вы используете jest для тестирования, а они используют mocha . Вы хотите, чтобы они также установили jest ? Просто Чтобы запустить свою библиотеку?

Нет. верно? Вот почему они находятся в devDependencies .

Когда кто-то это сделает, npm i yourPackage будут установлены только библиотеки, необходимые для RUN вашей библиотеки. Другие библиотеки, которые вы использовали для связывания своего кода или тестирования и имитации, не будут установлены, потому что вы поместили их в devDependencies . Довольно аккуратно, верно?

Итак, Зачем разработчикам нужно выставлять devDependancies ?

Допустим, ваш пакет является пакетом с открытым исходным кодом, и сотни людей отправляют запросы на включение вашего пакета. Тогда как они будут тестировать пакет? Они будут git клонировать ваше репо, а когда они сделают npm i зависимости , а также devDependencies .
Потому что они не используют ваш пакет. Они разрабатывают пакет дальше, поэтому, чтобы протестировать ваш пакет, им нужно пройти существующие тестовые случаи, а также написать новые. Итак, им нужно использовать ваши devDependencies , которые содержат все библиотеки тестирования/сборки/мока, которые ВЫ использовали.

0

Прекрасный пример:

 $ npm install typescript --save-dev
 

В этом случае вы хотели бы, чтобы Typescript (язык программирования с возможностью анализа javascript) был доступен для разработки, но после развертывания приложения в нем больше нет необходимости, так как весь код был перенесен в javascript. Таким образом, нет смысла включать его в опубликованное приложение. На самом деле, это только заняло бы место и увеличило время загрузки.

7

Как было предложено @andreas-hultgren в этом ответе и согласно документам npm:

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

Однако для разработки веб-приложений Yeoman (инструмент создания каркаса, который среди прочего устанавливает проверенный, предварительно написанный файл package. json) помещает все пакеты в devDependencies и ничего в зависимости, поэтому кажется, что использование --save-dev — это беспроигрышный вариант, по крайней мере, для разработки веб-приложений .

3

--save-dev сохраняет спецификацию semver в массив "devDependencies" в файле дескриптора пакета, --save вместо этого сохраняет ее в "зависимости".

4

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

Пример: экспресс, body-parser, lodash, шлем, mysql все они используются во время работы приложения используйте --сохраните для добавления зависимостей, в то время как мокко, стамбул, чай, sonarqube-scanner все используются во время разработки, поэтому поместите их в dev-dependencies .

npm link или npm install также установят модули зависимости dev вместе с модулями зависимостей в папке вашего проекта

Прочитать и забыть --save-dev Головная боль

Самый простой ответ состоит в том, что --save-dev полезен при создании пакетов для других разработчиков и хотят разместить ваш пакет в реестре NPM , например, lodash, mongoose, express и т. д. Когда вы создаете или пишете сервер узла , нет никакой разницы между --save и --save-dev , потому что ваша реализация Node Server является частной для вас, и вы никогда не опубликуете ее на NPM .

Как работает установка NPM

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

Как --save-dev связана с описанным выше материалом

Предположим, вы хотите создать новый пакет , например express , теперь, во время разработки этого нового пакета, вы, вероятно, захотите написать какой-нибудь модуль код тестирования и протестируйте пакет с любым другим доступным тестовым пакетом давайте в этом случае предположим мокко . Теперь вы знаете, что мокко требуется только для тестирования пакета не требуется для использования пакета . В этом случае вы должны установить mocha , используя флаг --save-dev , иначе NPM будет устанавливать его всякий раз, когда разработчик устанавливает ваш пакет, используя NPM . Поэтому, если мы хотим, чтобы зависимость не устанавливалась, когда кто-то устанавливает наш пакет из NPM мы должны установить этот пакет, используя --save-dev на этапе разработки.

Last Thing

Не смешивайте --save-dev с совместной разработкой , если кто-то клонировал код вашего пакета из исходной системы управления версиями, такой как github , тогда NPM будет обязательно установите все devDependencies т.е. пакет установлен с использованием --save-dev также.

Четкие ответы уже предоставлены. Но стоит упомянуть, как devDependencies влияет на установку пакетов:

По умолчанию npm install устанавливает все модули, перечисленные в качестве зависимостей в package.json. С флагом --production (или когда для переменной среды NODE_ENV установлено значение production ), npm не будет устанавливать модули, перечисленные в devDependencies .

См.: https://docs.npmjs.com/cli/install

Когда вы устанавливаете пакет npm с помощью npm install , вы устанавливаете его как зависимость.

Пакет автоматически указан в файле package.json в списке зависимостей (начиная с npm 5: раньше вам приходилось вручную указывать --save ).
экз. npm install lodash
После нажатия Enter проверьте файл package.json.

 "зависимости": {
    "лодаш": "4. x",
},
 

Когда вы добавляете флаг -D или --save-dev , вы устанавливаете его как зависимость разработки, что добавляет его к 92,6,1 дюйма },

Зависимости для разработки предназначены только для разработки и не нужны в рабочей среде. Например, тестирование пакетов, webpack или Babel.

Когда вы переходите в рабочую среду, если вы набираете npm install и папка содержит файл package.json , они устанавливаются, так как npm предполагает, что это развертывание для разработки.

Вам необходимо установить флаг --production ( npm install --production ), чтобы избежать установки этих зависимостей разработки.

0

Все объяснения здесь великолепны, но не хватает очень важного: как установить только производственные зависимости? (без зависимостей разработки). Мы отделяем зависимостей от devDependencies с помощью --save или --save-dev . Для установки всего используем:

 npm i
 

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

 npm i --only=production
 

Как правило, вы не хотите раздувать производственный пакет вещами, которые вы собираетесь использовать только для целей разработки.

Используйте опцию --save-dev (или -D ) для разделения пакетов, таких как среды модульного тестирования (jest, jasmine, mocha, chai и т. д.)

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

 npm install --save lodash // зависимость продукта
npm install -S момент // " "
npm install -S opentracing // " "
npm install -D jest //зависимость только для разработчиков
npm install --save-dev typescript //зависимость только для разработчиков
 92,8,3 дюйма
},
 

1

1. --save-dev (используется только в разработке, не в производстве)

2. --сохранить (производственные зависимости)

3. --global или -g (используется глобально, т. е. может использоваться в любом месте нашей локальной системы)

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

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

В основном пишем

 npm install имя_пакета
 

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

 npm install package_name --save-dev
 

в то время этот пакет был установлен только в целях разработки.

Я хочу добавить некоторые из моих идей как

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

Например, вы пишете HTTP-библиотеку с именем запрос узла

В вашей библиотеке,

вы использовали lodash для обработки строк и объектов, без lodash ваши коды не могут работать

Если кто-то использует вашу HTTP-библиотеку как часть своего кода. Ваши коды будут скомпилированы с его.

ваши коды нужны lodash, поэтому вам нужно ввести зависимости от до compile

---

Если вы пишете проект, например monaco-editor , который является веб-редактором,

вы объединили все свои коды и свою библиотеку env продукта с помощью webpack при сборке завершено, есть только monaco-min.js

Так что кому-то все равно, --save или --save-dependencies , ему нужен только monaco-min.js

Резюме: 900 06

1. Если кто-то хочет скомпилировать ваши коды (использовать как библиотеку), поместите lodash , который используется вашими кодами, в зависимостей

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

поскольку --save является параметром по умолчанию для npm, поэтому я использую пакет

 npm i
 

и для --save-dev я использую

 npm i package -D
 

опция по умолчанию установит пакет как зависимость от проекта, где -D для зависимостей разработки, таких как тестирование, lint и т.