я был вовлечен вreactОсновной интерфейсный проект охватывает три платформы: Web, Android и iOS. Так как вся бизнес-логика сосредоточена на мобильном терминале, а веб-терминал не запускается до середины проекта, я используюreact-nativeа такжеreactДва проекта были построены отдельно.
Однако серверный микросервисный кластер один и тот же, и API, вызываемые двумя проектами, в основном одинаковы, что неизбежно приводит к некоторому дублированию логики в двух проектах. Например, код бизнес-логики, написанный на редуксе, код обработки запросов, написанный на http-перехватчике и т. д., эти повторяющиеся части можно увидеть невооруженным глазом по имени каталога и имени файла.
Я попытался инкапсулировать повторяющиеся части в отдельныеnpmНа пакет ссылаются два проекта, но этот метод подходит только для кода инструмента, который меняется реже.После инкапсуляции кода бизнес-логики, который часто меняется, его также сложно использовать. Во-первых, разрабатывать и отлаживать вне проекта непросто, во-вторых, бизнес-код слишком часто обновляется в процессе разработки проекта, и зачастую приходится постоянно обновлять версию. Взвесьте все за и против, и, в конце концов, выгоды перевешивают потери.
Итак, есть ли способ лучше повторно использовать эту часть логики кода? Есть ли способ извлечь общий код этих двух проектов в независимые проекты, но избежать инкапсуляции в независимые проекты?npmПакет неисправностей этого?
Я недавно пытался импортироватькаркас lerna, используя эту архитектуру большого внешнего интерфейса в качестве эталона для трансформации, я был приятно удивлен, обнаружив, что она не только решила проблемы проекта в то время, но и принесла некоторые дополнительные преимущества, связанные с управлением несколькими проектами.
На самом деле многие проекты в сообществе с открытым исходным кодом уже использовали эту многопроектную схему интеграции, и большинство кодовых баз, использующих lerna framework, знакомы, например зарубежные.babel,create-react-app,react-router,jest, а также отечественный кросс-энд апплетTaro.
Наконец, после преобразования два проекта были объединены в один, а повторяющаяся логика кода также была извлечена в другой независимый проект.Вся структура проекта стала такой, как показано ниже.
Представьте лерну
lernaНазвание происходит от Лернейской гидры в греческой мифологии и является подходящим описанием многопроектной инженерии.
lernaВведениеlerna, а импортировать вlernaболее подходящим, поскольку конкретный подход заключается в создании нового через командную строкуlernaproject, а затем импортировать в него все проекты. И одновременно с импортом записи git commit каждого проекта также объединяются.
lerna init
lerna import 你本地的项目路径
Каждый импортированный проект будет храниться в каталоге пакетов корневого пути.Ниже приведен скриншот моего демонстрационного проекта.Всего было представлено три подпроекта: rntest, веб-приложение, общий доступ. Представляют мобильный, веб- и многоразовый логический код соответственно.
Используйте lerna для управления зависимостями проекта
представлятьlernaПосле, первым делом нужно разобраться с проблемой установочных зависимостей, нам нужно использоватьlerna addкоманда вместо того, к чему мы привыклиnpmилиyarn, например, для установки проекта rntestlodash, выполните следующую команду.
lerna add lodash --scope=rntest
Однако после выполнения вы обнаружите, что package-lock.json в других проектах изменился, что очень сбивает с толку.Причиной этого является команда установки, которая автоматически выполняется после добавления зависимостей.lerna bootstrapСвязанный.
Повышение зависимости для lerna
lernaв состоянии пройтиlerna bootstrapОднострочная команда устанавливает пакеты зависимостей всех подпроектов, и при установке зависимостей существует функция продвижения зависимостей.Так называемое «продвижение зависимостей» заключается в обновлении всех файлов зависимостей проекта npm в корневой каталог, что позволяет избежать того же пакет зависимостей в разных проектах.Установить несколько раз. например несколько проектовredux, благодаря продвижению зависимостей несколько проектов нужно загрузить только один раз. Однако требуются дополнительные параметры--hoistПусть усиление зависимости вступит в силу.
lerna bootstrap --hoist
но автоматическиlerna bootstrapКоманда не принимает параметр расширения зависимости, поэтому файл блокировки каждого из вышеуказанных проектов будет изменен.
Конечно, эту проблему также легко решить,lernaКонфигурация, позволяющая избежать модификации файла блокировки npm, может быть написана следующим образом:
Пряжа - лучший партнер для Лерны
lernaПо умолчаниюnpmВ качестве инструмента пакета зависимостей установки, но можно выбрать и другие инструменты.yarnПосле версии 1.0 предоставляется функция рабочих пространств, которая обеспечивает продвижение зависимостей с более низкого уровня, и делает такие вещи, какlernaтакой же. следуй за нимlernaВ совокупности это почти какlernaТо же по индивидуальному заказу. Поэтому рекомендуется использовать его с пряжей в lerna.
Чтобы заменить NPM с пряжей, вам нужно только добавить две строки кода в файл конфигурации LERRA, и это будет сто раз гладным сразу после конфигурации.
Эффективное повторное использование кода
В этом крупном интерфейсном проекте, в котором я участвовал, часть дублирования кода между несколькими терминалами включаетreduxБизнес-логика в , обработка http-запросов, проверка инструментов спецификации кода,gitПользовательские скрипты в хуках и многое другое. существуетlernaВ соответствии с архитектурой первые два могут быть напрямую извлечены в независимый проект, а затем на них могут ссылаться другие проекты.Например, в моей демонстрации он может быть напрямую импортирован, как и другие зависимые пакеты.sharedпроект, lerna автоматически распознает его и направит во внутренний проект.
import shared from 'shared'
Это непосредственно инкапсулировано вnpmБольшая разница между пакетами в том, что они обновляются в реальном времени, и изменения видны сразу, как и в одном проекте, не затрагивая разработку и отладку.
Повторное использование git-хуков и пользовательских скриптов
я пытаюсь справитьсяgitкрюк инструментhuskyУстановленные в корневом каталоге инициированные события и пользовательские сценарии могут охватывать каждый проект, что обеспечивает большое удобство повторного использования этой части кода. Например, во многие проекты добавляются собственные скрипты для ограниченияgit commitОписание сообщения при отправке, вlernaПод архитектурой просто напишите один раз.
Повторное использование eslint
Те сторонние зависимости, которым часто требуется добавлять файлы конфигурации в корневой каталог, такие какeslint,prettier,babelподожди, вlernaНевозможно объединить простые и грубые акции в одном месте. Следовательно, дляeslintЭто незаменимый инструмент для front-end разработки.Можно попробовать извлечь все элементы конфигурации в самостоятельные проекты, а затем установить сторонние зависимости для их внедрения, аналогичноeslint-config-airbnb,eslint-config-prettier,eslint-config-googleтак.
Я должен сказать, даже еслиlernaFramework мы можем сделать то же самое, но вlernaМодификации под фреймворком видны сразу, облегчая отладку и разработку.
CI/CD в рамках lerna framework
Многопроектная структура, несомненно, даетCI/CDВозникают проблемы, но, к счастью, основная среда CI может прекрасно решить эту проблему. Например, на гитлабеonly/changesПараметры полностью соответствуют нашим потребностям, что позволяет нам установить отдельный конвейер для каждого подпроекта, например, сейчас мы настраиваем конвейер, который будет запускаться только при изменении файлов в рамках проекта rntest:
В рамках lerna все проекты объединяются в один проект, ноCI/CDЭто не должно быть так. Настроив ключевые параметры в скрипте наCI/CDВ проекте поделитесь той же копией.gitlab-ci.ymlфайл, чтобы каждый подпроект соответствовал независимомуCI/CDпроект, финалCI/CDСтруктура выглядит следующим образом:
Разрешения подпроекта в lerna framework
Так как все проекты объединены в одинlernaВ рамках проекта, когда у вас есть права доступа, вы можете изменять код во всех подпроектах, что принесет некоторые проблемы в реальной разработке. Например, разработка веб-платформы и разработка мобильной платформы — это две разные команды.Как член веб-команды, что мне делать, если я случайно изменю или удалю файлы мобильного проекта? Если не добавлять никаких ограничений, такое рано или поздно произойдет, я думаю, что это может бытьlernaФреймворки имеют врожденные болевые точки.
К сожалению, вlernaВ рамках фреймворка сторонние платформы для размещения кода, такие как gitlab или github, не могут решить эту проблему с помощью собственных функций управления правами. Но, к счастью, есть и другие инструменты, помогающие облегчить эту боль. Я пытаюсь использовать инструменты, чтобы ограничить участников с открытым исходным кодом отправкой PR-спецификаций.dangerjsЧтобы завершить разделение разрешений, используемая информация — это имя пользователя текущей учетной записи gitlab, что, кажется, работает хорошо.
Видно, что этот инструмент будет судить, что моя учетная запись gitlab не имеет разрешения на изменение файлов в подпроекте rntest при слиянии MR, тем самым запрещая слияние этого MR и автоматически добавляя эту информацию в комментарии MR. Конечно же, скрипт написан мной только для демонстрации, а логика относительно проста, код скрипта такой:
оdangerjsЯ напишу отдельную статью, чтобы представить подробности.
Эпилог
Большие фронтенд-проекты станут тенденцией фронтенд-разработки Как лучше управлять большими фронтенд-проектами — это тема, которую не может избежать каждый фронтенд-разработчик.lernaФреймворк предлагает решение через концепцию одного, и мы можем играть через развитие экономики.lernaмаксимальная полезность. Если вы еще не использовали его, возможно, попробуйте его для следующего проекта.
Релевантная информация