Nrwl Nx: разные номера версий и библиотеки

Question

Я хочу начать проект Angular, используя Nrwl Nx (несколько приложений в одном проекте; https://nrwl.io/nx), но у меня есть два вопроса:

1. Как я могу указать разные номера версий для разных приложений? Обычно я даю номер версии в package.json, но с Nx есть только один package.json для всех моих приложений. Должен ли я положить его в файлы среды? Или в .angular-cli.json файл?

2. Я прочитал это: "Обновление до lib требует изменений для всех разработчиков". Есть ли какое-либо решение (обход) для использования разных версий пакета lib или NPM в разных приложениях? Здесь только один node_modules, но это важно для моих приложений.

Как вы знаете, структура проекта Nx выглядит следующим образом:

apps
    app1
    app2
libs
    lib1
    lib2
node_modules
package.json
.angular-cli.json
...

Возможно, эти два вопроса основаны на мнении (я не очень уверен в этом), но статей о Nrwl Nx очень мало, и ответы могут помочь и другим. Спасибо.

Answer 1

У меня есть несколько идей. Я работаю с NX Extensions каждый день, и ИМХО, полагаясь на то, что "это не способ моно репо", можно считать идеальным вариантом, но на практике он не работает. Вы рано или поздно захотите внести критические изменения в библиотеку, и вы не хотите, чтобы все ваши тесты в приложениях давали сбой, когда вы это делаете (не позволяют вам выпустить и т. Д., На что у вас может не хватить времени убрать). Возможно, это не совсем то, к чему стремится OP, но я думаю, что с небольшим изменением в мышлении эти решения могут служить. Я их все перепробовал, вроде работают.

Обратите внимание, что я знаю способ Google (я там работал). Я столкнулся с этой проблемой в первом проекте, над которым работал. Их среда разработки обеспечивает аналог "если бы у вас были разные package.jsons в каждом приложении...", поэтому сравнение NX с внутренней системой Google как абсолютного 1:1 немного неуместно.

Определитель: это не "ответ". Он просто рассказывает о некоторых способах решения этих проблем.

• Разветвите все репо, назовите это версией. Сделайте свое критическое изменение, посмотрите, как все развалится. Все исправить, обновить с мастера, выглядит хорошо, слить. Необязательно: выпуск из этой ветки.

Эта "ветвь разработки" работает для большинства вещей, связанных с "нарушением изменений библиотеки".

• В tsconfig.json, если вы используете псевдоним своей библиотеки (@myorg/blah), ваше приложение будет указывать на настроенный вами путь. В мастере создайте свою библиотеку (ng-packagr). Используя конфигурацию вывода, вы можете вызывать dist как хотите (@myorg/blah-v1, v2, сколько угодно). Укажите на него tsconfig (tsconfig будет указывать на путь без сборки). Мастер теперь будет использовать заблокированную известную версию библиотеки (только НЕ ПЕРЕСТРОЙТЕ ЕЕ С ИЗМЕНЕНИЯМИ). Теперь вы можете злоупотреблять своей основной библиотекой по своему усмотрению. Чтобы сохранить мышление "все в мастерской работает", вы должны ветвиться master, а затем внести это изменение, которое позволит вам работать с библиотекой независимо от приложений, которые ее используют, с нетронутым master.

• Создайте свою библиотеку (с версией и предполагает ng-packagr), упакуйте ее с помощью npm (теперь у вас есть архив), делайте с ней все, что хотите. Мастер ветки, удалите запись пути из tsconfig, добавьте запись установки в package.json (вы можете установить из файла), и ваши приложения должны подобрать ее (опять же, псевдонимы импорта должны совпадать). Вы также можете выполнить установку в мастере (известная рабочая версия как tarball) и снова использовать свои библиотеки по своему усмотрению.

Последнее решение я немного протестировал и убедился, что оно работает, но если вам не нужно упаковывать tarball и связываться с package.json, зачем беспокоиться. Тем не менее, это хороший вариант, и он не влечет за собой недостаток, заключающийся в невозможности перестроить библиотеку (поскольку вы перезапишете известную рабочую версию, если не измените цель вывода).

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

Я тоже выложу их туда:

Основным преимуществом монорепозитория является то, что он заставляет вас избегать технического долга, который вызывают несколько версий библиотеки, что является СЕРЬЕЗНЫМ, если вы отпустите его на какой-то период времени. Если вы позволите ему продержаться достаточно долго, рано или поздно у вас возникнут проблемы с общей версией Angular, чего вы ХОТИТЕ избежать.

Если доходит до того, что у вас есть приложение, которое требует большого дрейфа, ИМХО, вам лучше всего было бы создать новое репо, сбросить в него код, стереть его из основного репо, подождать, пока он не попадет в форму и положите обратно, когда она будет готова (если когда-либо).

И помните, когда вы работаете над библиотекой, вам нужно думать немного по-другому. Это общий код, и каждый раз, когда вы вносите в него изменения, он не может сломаться. Вместо того, чтобы переименовывать этот ввод, создайте другой и укажите его на оригинал (обратная совместимость) и тому подобное. Узоры-декораторы и все такое. Критическое изменение в библиотеке НЕ должно происходить случайно.

Надеюсь, это поможет.

Answer 2

Технически невозможно указать разные номера версий для разных приложений в рабочем пространстве NX, поскольку рабочее пространство NX основано на monorepo (это технология, используемая ведущей ИТ-компанией, такой как Google, Facebook и т. Д.).

Да, вы можете указать разные номера версий для разных приложений путем реструктуризации рабочего пространства NX, но технически это не будет однообъемное рабочее пространство NX.

Answer 3

Как уже ответил JBecton, "путь Nx" - это создать один package.json.

В вашем случае вам нужно отделить управление версиями вашего приложения от контроля версий моно-репо.

Сгенерированные угловые файлы среды.ts являются правильным местом для этого.

Answer 4

Nx использует подход MonoRepo, поэтому ваши приложения и библиотеки будут иметь одинаковую версию. https://nrwl.io/nx/why-a-workspace

Answer 5

Согласно концепции Monorepo, все приложения должны входить в один и тот же зонтик, что означает, что они находятся в одном репозитории, и поддерживать несколько приложений в одном монорепозитории очень сложно с разными версиями. Также наличие одного файла пакета гарантирует, что при обновлении рабочей области все приложения обновляются по умолчанию. Это должно быть стандартом для любой организации, чтобы все приложения были в одной версии.