В последнее время у меня есть время заняться некоторыми своими делами, я обнаружил интересную проблему посередине, которая исправила мое многолетнее неправильное мышление, поэтому я отправил блог, чтобы записать это.
Отвечать
Давайте сначала подведем итоги. Если это обычный интерфейсный проект, на самом деле пакеты зависимостей в package.json в основном совпадают с зависимостями разработки и производственными зависимостями. Даже если все пакеты зависимостей в package.json проекта перешел на devDependencies, проблем нет. Если проект представляет собой пакет npm или службу узла, будет небольшая разница.
задний план
Все мы знаем, что зависимости в package.json соответствуют зависимостям рабочей среды, а devDependencies — зависимостям среды разработки. использоватьnpm installПри добавлении --save добавляется в зависимости, --save-dev добавляет модуль в раздел devDependencies.
Изучая gatsby.js, я обнаружил, что официальная рекомендация — установить typescript в зависимостях...
Мне было любопытно, потому что, по моему мнению, ts ограничен только статической проверкой типов, а реальная производственная линия — это js, зачем помещать его в зависимости? Будет ли он включен в конечный продукт, когда он выйдет в эфир?
Поэтому я погуглил, где следует размещать typescript, и нашел много таких проблем.Одна из них заключалась в том, что typescript по умолчанию добавлялся к зависимостям в create-react-app, что также вызывало вопросы у других, см. рисунок ниже.
вопросы и ответы
Дэн (разработчик React) сказал: "Не беда, можешь ставить куда хочешь😜"...
Затем он последовал за абзацем и кратко объяснил:
Различие между зависимостями и devDependencies имеет смысл для служб приложений Node, поскольку они фактически развертываются как среды выполнения. Поэтому вы, вероятно, не хотите развертывать devDependencies.
Для скаффолдинга, такого как create-react-app, конечным результатом является статический пакет. Так что в некотором смысле все зависимые пакеты должны быть «зависимостями», даже React или библиотеки, которые вы используете. Потому что они используются только во время сборки.
Помещение всех зависимостей в devDependencies может нарушить работу некоторых сценариев развертывания, выполняющих первоначальную сборку на сервере. Так проще поместить все зависимости в зависимости.
Указанный адрес выпуска👇
Есть аналогичный вопросGitHub.com/Facebook/взрослый…
принцип
зависимости и devDependenciespackage.jsonвнутри конфига, аpackage.jsonа такжеnode_modulesЭтот набор механизмов загрузки пакетов зависимостей разработан узлом.
Если мы разрабатываем нод-приложение, серверную службу необходимо развернуть в сети, и мы должны строго различать зависимости и devDependencies, потому что сам проект находится в состоянии выполнения.
Так же есть разница в разработке npm пакетов.Предположим мы разрабатываем npm пакет А и публикуем его.В проекте вводится зависимый пакет А.Если А скачивается то он тоже имеет свойnode_modules, если в зависимостях A есть B, а в зависимостях есть B, то он будет загружен в зависимости A вместеnode_modules, если он предназначен для разработки, он не будет загружен, поэтому, когда мы пишем npm-пакет A, мы должны поместить зависимости разработки, такие как webpack, gulp или jest, в devDependencies, чтобы уменьшить размер загружаемого пакета, когда другие используют A.
Если это обычный интерфейсный проект SPA, это действительно не имеет значения, потому что мы фактически используем файл статической страницы, созданный проектом, а развернутая страница — это только продукт, упакованный и созданный веб-пакетом, поэтому пакет зависимостей помещается в зависимостях ничем не отличается от devDependencies.
Но скажем кое-что еще: некоторые скрипты автоматической сборки проекта сборки добавят параметр --production.В это время пакет devDependencies не будет подтягиваться, что приведет к ненормальному процессу сборки, поэтому Дэн предлагает попробовать поместить их в зависимости как как можно больше!
расширять
Если вам интересно, вы также можете узнать, что такое зависимости: peerDependencies, bundledDependencies и optionalDependencies, но будьте осторожны при их использовании!