Может ли один модуль Node использовать зависимости от модуля узла, от которого он зависит? - PullRequest
0 голосов
/ 24 сентября 2018

TL; DR;Возможно ли реализовать наследование пакетов в Node?Или есть рекомендуемый инструмент, чтобы помочь с этим?

Я работаю в корпоративной среде, содержащей более 60 (и растущих) веб-приложений.У нас также есть модульные компоненты, такие как header / footer / sign-in / etc.поэтому веб-приложениям не нужно повторять код, и они могут просто использовать их как зависимости.У нас также есть библиотечные модули для таких вещей, как ведение журнала, моделирование и обработка ошибок.У нас также есть одна основная библиотека, которая обеспечивает основу для обслуживания, такого как тестирование и связывание.

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

lib-a   
   |   
   —> lib-b  
         |
         —> babel, chai, mocha, etc.

Я бы хотел, чтобы lib-a «наследовала» babel, chai, mocha и т. Д. От lib-b, вместо того, чтобы специально добавлять зависимости.Таким образом, все мои библиотеки и, в конечном итоге, веб-приложения будут иметь одинаковую версию, и мне не придется повторять одни и те же зависимости в каждом package.json.Мне также не нужно будет испытывать головную боль, когда N команд будет обновлять 60-100 apps / libs / whatnot и иметь дело с ними, жалующимися на техническое обслуживание.

Я понимаю, что это идет вразрез с ядром npm, но на том уровне, на котором мы его используем, это становится головной болью при обслуживании.Увеличение количества DRY определенно принесло бы свои преимущества на этом этапе.

Итак, чтобы повторить первоначальный вопрос вверху - возможно ли реализовать наследование пакетов в Node?Или есть какие-нибудь рекомендуемые инструменты, чтобы помочь с этим?

Я видел следующие инструменты.Кто-нибудь когда-либо использовал их?или есть мысли о них.Есть ли другие?
https://github.com/FormidableLabs/builder
https://github.com/Cosium/dry-dry

1 Ответ

0 голосов
/ 25 сентября 2018

Это плохая идея.Вы должны предположить, что у вас нет контроля над зависимостями.Как еще кто-нибудь сможет внести изменения в зависимости?

Предположим, lib a из вашего примера использует mocha.Поскольку это зависит от lib b, который также зависит от mocha, вы можете не указывать mocha в lib a package.json.

Если кто-то рефакторирует lib b, чтобы он больше не использовал mocha, lib a внезапно упадет.Это не хорошо.

Мы работаем с одинаковым количеством проектов.Мы используем Greenkeeper , RenovateBot и некоторые инструменты, которые применяют изменения ко всем нашим репо сразу.В долгосрочной перспективе это, вероятно, лучшая стратегия для вас, чем идти против модели зависимостей Node.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...