Обновление:
Мое оригинальное решение, приведенное ниже, является хакерским и имеет некоторые недостатки.С другой стороны, pnpm , как подсказывает @sachin Gupta, кажется простым решением вашей проблемы .Я еще не пробовал, но если документация не лжет, это действительно так просто, как , следуя инструкции по установке , а затем просто используйте команду $ pnpm вместо $ npm для установки зависимостей вашего проекта.
Хранение общих зависимостей в корневой папке
Чтобы решить вашу проблему, нужно, чтобы все папки вашего проекта были вложенными папками другой -летки, называя ее root -, что, в свою очередь,также имеет package.json и node_modules.Этот root проект имеет все общие зависимости dev, которые разделяют ваши проекты: webpack, babel, node-sass и т. Д.
Пример структуры папки
. root/
+-- node_modules/
+-- package.json
| +-- web-project-1/
| +-- package.json
| +-- src/
| +-- main.js
| +-- index.html
| +-- dist/
| +-- index.html
| +-- web-project-1/
| +-- package.json
| +-- src/
| +-- main.js
| +-- index.html
| +-- dist/
| +-- index.html
Это только пример.Единственная важная часть заключается в том, что зависимости dev находятся в папке node_modules родительского ваших проектов.
Хорошие части
Любые import или require в дочерних папках будут использовать узлы root.Таким образом, код вашего приложения будет использовать родительский node_modules без необходимости дальнейшей настройки.Это поведение по умолчанию для node.js, когда вы выполняете require в любом дереве папок: если он не находит node_modules в рабочем каталоге, он всегда ищет node_modules в родительских каталогах до корневой папки.
Любой скрипт npm в дочерних элементах, использующих двоичные файлы node_modules, также будет их использовать.Это аккуратно.Поэтому, если в какой-либо из дочерних папок у вас есть проект с webpack в качестве сценария npm, определенного в package.json, вы можете вызвать его из командной строки: npm run webpack без необходимости устанавливать node_modules в дочернем элементе.папка.
Так, в примере, если root 'node_modules имеет зависимость tslint, вы можете настроить web-project-1/package.json сценарии, такие как:
"scripts": {
"lint": "tslint --project . --fix"
},
И когда вы запускаете npm run lint в терминале, для выполнения этой команды будут использоваться двоичные файлы root node_modules.
То же самое происходит для всех остальных разработчиковзависимость, как webpack, gulp, node-sass или тому подобное.
Плохие части
Плохая часть в том, что если вы npm install любой из детей из ихpackage.json, зависимости, перечисленные в этом package.json, будут установлены и у детей, даже если они уже присутствуют у родителя.Это делает этот подход довольно неприятным, если вы хотите объявить детские dev-зависимости в их package.json: вам следует вручную удалять дублирующиеся deps у детей каждый раз, когда вы выполняете npm install.
Однако, так каквы поставляете только папку dist, вам не нужно перечислять зависимости dev каждого проекта в его package.json.Если вам когда-нибудь понадобится работать с другим разработчиком, вы можете передать им root package-json, чтобы они получили правильные зависимости dev.
Преимущество этого подхода перед вашим заключается в том, что вам не нужно вручную устанавливать символические ссылки в каждом package-json нового проекта.
Ключевые моменты
- Родитель должен иметь все зависимости dev для проектов.
- Невозможно перечислить зависимости dev для дочерних элементов
package.json, если вы не хотите вручную удалять их из node_modules послекаждый npm install, что, как мне кажется, слишком хлопотно. - Если вам когда-либо понадобится другая версия зависимости в одном конкретном проекте, вы на самом деле можете перечислить ее в
package.json: он будет установлен в детской node_modules.