Angular 9 библиотека с круговой зависимостью точек входа

Question

У меня очень специфический c вопрос о настройке дополнительных точек входа библиотек angular Я действительно не понимаю, как я могу настроить его так, чтобы он работал, когда они зависят друг от друга, включая основную точку входа. Я прочитал документы для ng-packagr и много вопросов и вопросов по стеку, но не нашел действительно хорошего ответа. Дело в том, что я хочу разбить нашу большую внутреннюю библиотеку на более мелкие части, чтобы импорт и зависимости становились меньше для приложений, которым не нужно все.

Так вот, что я хочу для достижения:

• Основной lib @ my / my-lib
• вторичный путь @ my / my-lib / functions
• вторичный путь @ my / my-lib / constants
• вторичный путь @ my / my-lib / lang
• вторичный путь @ my / my-lib / broker
• вторичный путь @ my / my- lib / signalr
• вторичный путь @ my / my-lib / sso
• вторичный путь @ my / my-lib / types

, и это структура папки:

projects\my-lib
-- constants\
---- ...
---- package.json
---- public_api.ts
-- functions\
---- ...
---- package.json
---- public_api.ts
-- lang
---- ...
---- package.json
---- public_api.ts
-- broker
---- ...
---- package.json
---- public_api.ts
-- signalr
---- ...
---- package.json
---- public_api.ts
-- sso
---- ...
---- package.json
---- public_api.ts
-- src <-- the main entry point, as setup from the ng g library
---- lib
------ modules <-- the old ones from where i want to source parts out in secondary paths
-------- auth
-------- config
-------- footer
-------- header
-------- log
-------- state
-------- ...
---- public_api.ts
-- ng-package.json <-- main entry point
-- package.json <-- main entry point

Теперь вот моя проблема:

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

Теперь, когда я хочу импортировать что-то из @my/my-lib/lang в основной файл @my/my-lib и обратно, я получаю предупреждение о циклической зависимости от себя. Это звучит, во-первых, логично для меня, потому что ng-packagr не знает, что собирать первым.

До сих пор я читал, что вторичные точки входа получают сборку первыми каждый раз, это будет работать идеально, когда у меня нет зависимостей от @my/my-lib/lang до служб внутри @my/my-lib, так как я могу настроить это так, чтобы я мог импортировать вещи в @my/my-lib/lang из @my/my-lib и наоборот?

Answer 1

По моему опыту, вторичные точки входа создаются после основной точки входа, если вы используете Angular CLI. Единственными возможными ссылками, которые вы можете иметь, является ссылка на основную библиотеку из дополнительных точек входа. Вы можете иметь ссылки между вторичными точками входа снова только в одном направлении. Во время сборки ссылки разрешаются и определяется порядок сборки вторичных точек входа, поэтому они строятся в порядке ссылок.

Для вашего примера единственное, что вы можете сделать, - это импортировать вещи из @my/my-lib внутри @my/my-lib/lang, а затем в @my/my-lib/lang импортировать, например, @my/my-lib/types.

Импорт должен осуществляться в библиотеку, а не в файл напрямую.

import { MainLibClass } from '@my/my-lib';
import { MyType} from '@my/my-lib/types';

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

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