Почему npm имеет 2 категории зависимостей?

Question

В вашем package.json у вас есть dependencies и devDependencies.

{
  "devDependencies": {
    "webpack": "^4.42.1"
  },
  "dependencies": {
    "react": "^16.13.1"
  }
}

Я понимаю, что:

• dependencies - это deps, которые нужны вашему приложению run
• devDependencies - это депы, которые вам нужны только во время разработки

Но почему их нужно так разделять? Каковы преимущества?

Что произойдет, если я это сделаю?

{
  "dependencies": {
    "react": "^16.13.1",
    "webpack": "^4.42.1"
  }
}

Есть ли какие-либо потери производительности? Будет ли разделение дел иметь значение, только если я захочу опубликовать sh модуль?

---

Этот вопрос не имеет ничего общего с: В чем разница между зависимостями, devDependencies и peerDependencies в npm package. json file?

Этот вопрос задает вопрос, что dependencies и devDependencies являются . Я четко сказал, что они выше.

Этот вопрос о , почему вы бы хотели разделить все подобные дела. Кажется, что некоторые люди создают свое приложение на своем сервере. Я обычно строю в автономном режиме и просто отправляю артефакты index.html и main.js. Поэтому некоторые из этих пунктов не применимы к моей текущей ситуации.

Кроме того, после небольшого дополнительного тестирования кажется, что ваш devDependencies фактически не попал в ваш main.js комплектный файл. По крайней мере, в том, как я настроил свой проект, я не видел разницы в размере между разделением моих deps и тем, чтобы все они были под dependencies. А поскольку я просто отправляю артефакт сборки, это никак не влияет на мой производственный опыт.

Answer 1

Наличие двух категорий полезно, потому что вы не хотите, чтобы вещи времени разработки упаковывались вместе с вашим кодом, когда вы публикуете sh его. Например, у вас может быть несколько npm пакетов для целей разработки (например, jest, linting tools или prettier), но вы не хотели бы, чтобы они были добавлены в код, который другие получают при установке вашего пакета. Это сделает ваш пакет больше, чем нужно.

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

'npm' - менеджер пакетов Node, и он выполняет свою работу по Для упаковки модулей узла необходимо знать, что необходимо для построения кода и что необходимо во время выполнения при использовании кода. Если вы go попали в репозиторий git проекта и клонировали его, вы можете сделать npm install и получить среду разработки. Это загружает все модули зависимости в node_modules/. Однако вам не нужно все это, когда вы используете модуль. При использовании модуля вам просто нужен dependencies, а не devDependencies. Именно здесь npm нужно знать разницу, потому что его работа заключается в обработке пакета модуля.

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

На других языках у вас может быть make-файл, который выполняет сборку и знает, что исключить тестовые папки, исходные папки и т. Д. c и упаковывать только то, что нужно во время выполнения. Например, с Java вы можете создать файл .jar, который исключает только для разработки такие вещи, как модульные тесты. Думайте о package.json как о make-файле, а раздел devDependencies как о подсказке сборщику того, что нужно исключить при сборке компонента времени выполнения.