Как обрабатывать общие зависимости при совместном использовании компонентов между несколькими приложениями в монореполе - PullRequest
0 голосов
/ 20 февраля 2019

У меня есть следующая структура monorepo

root
--AppOne
----package.json
----node_modules
------styled-components

--AppTwo
----package.json
----node_modules
------styled-components

--Shared
----componentA
----package.json
----node_modules
------styled-components

Моя проблема в том, что и AppOne, и AppTwo используют componentA из каталога shared, и это зависит от пакета NPM, дляпример на styled-components

Это означает, что мне нужно установить styled-components во всех трех каталогах, и это увеличивает размер пакета, и если версии не совпадают, это может вызвать проблемы с пакетом, который делает то, чтоэто должно быть сделано.

Это также означает, что я получаю следующую ошибку от styled-components:

It looks like there are several instances of 'styled-components' initialized in this application. This may cause dynamic styles not rendering properly, errors happening during rehydration process and makes your application bigger without a good reason.

Мой вопрос - каков наилучший способрешить эту ситуацию?В идеале я хочу, чтобы этот пакет устанавливался только в одном месте.Должен ли я установить его в Shared и использовать псевдоним в AppOne и AppTwo для использования пакета?

Любой совет, который высоко ценится!

1 Ответ

0 голосов
/ 28 февраля 2019

Работая над большим монорепо, я скажу, что есть много способов решить эту проблему, написав собственные сценарии и вызывая их в npm "post-install".Возможно, вы также можете вручную поддерживать эту взаимосвязь между зависимостями в каждом из пакетов.json's peerDependencies.

Я предпочитаю полагаться на инструменты для управления взаимозависимостями.В моем проекте я использую Lerna, которая имеет функцию поднятия пакета именно для этого случая использования.Если Lerna для вас излишня, вы должны знать, что подъем пакетов также предоставляется Yarn Workspaces .На самом деле, когда Lerna используется поверх Yarn, Lerna просто делегирует подъем пакета рабочим пространствам Yarn, так что вам действительно не нужна Lerna для этого.

Я также слышал о Болте в этом отношении, но по состоянию на начало 2019 года он очень перспективный, но гораздо менее зрелый, чем Пряжа / Лерна.

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