Node отлично справляется с символическими ссылками. Как достичь этого, будет зависеть от некоторых ваших целей. Самое главное: какой опыт вы хотите предоставить другим разработчикам, которые загружают ваш проект(ы) из системы контроля версий?
При разработке этого опыта очень полезно прочитать об алгоритме загрузки модулей Node, чтобы получить представление о том, что возможно.
В общем, я рекомендую не беспокоиться о дублирующихся зависимостях между проектами. «Исправление» этого не стоит затрат на обслуживание, которое включает в себя блокировку зависимостей (противоречащие потребности подпроектов) и необходимость в пользовательских инструментах в некоторых случаях для учета вашей пользовательской структуры.
Когда это предупреждение убрано, как нам это сделать? Самый простой способ — создать суперпроект, который инкапсулирует различные подпроекты. Подпроекты фактически наследуют зависимости суперпроекта.
superproject/
|-- node_modules/
| +-- socket.io/
|-- package.json
|-- subprojectA/
| |-- node_modules/
| | +-- browserify/
| |-- package.json
| +-- app/
| +-- client.js
+-- subprojectB/
|-- node_modules/
| +-- express/
|-- package.json
+-- lib/
+-- server.js
Эта структура работает, как и следовало ожидать, файлы внутри подпроектов могут require()
использовать свои собственные модули и любые из тех, что находятся в superproject/node_modules
, но они не будут легко require()
модули в своих родственных подпроектах (это все еще возможно сделать с помощью явных путей). Другими словами, client.js может require()
браузерировать и socket.io без пути, но ему нужно будет использовать путь к require()
экспрессу.
Важным аспектом этого является то, что npm
выполняет поиск package.json и работает с модулями в каталоге node_modules
как родственным этому файлу при установке и т. д. Это означает, что ваш текущий рабочий каталог должен быть superproject
для установки в него модулей, если только в вашем подпроекте нет файла package.json
.
person
Seth Holladay
schedule
27.03.2016