Несколько корневых модулей на угловом применении - PullRequest
Новая
       42

Несколько корневых модулей на угловом применении

1 голос
/ 05 апреля 2019

Я занимаюсь разработкой сайта на Angular. Это приложение разделено на две части: часть клиента и часть администратора. Последний доступен через экран входа в систему. Ядро этого механизма сделано с этими двумя файлами:

main.ts: 

import {enableProdMode} from '@angular/core';
import {platformBrowserDynamic} from '@angular/platform-browser-dynamic';

import {AppModule} from './app/app.module';
import {environment} from './environments/environment';
import {AdministrationModule} from "./administration/administration.module";

if (environment.production) {
    enableProdMode();
}

if (window.location.href.indexOf("admin") != -1) {
    platformBrowserDynamic().bootstrapModule(AdministrationModule);
}

else {
    platformBrowserDynamic().bootstrapModule(AppModule);
}

index.html: 

<!doctype html>
<html lang="it">
<head>
    <meta charset="utf-8">
    <title>MyWebsite</title>
    <base href="/">

    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="icon" type="image/x-icon" href="icon.ico">
</head>
<body>
<app-root></app-root>
<app-administration></app-administration>
</body>
</html>

Обычно, если я обычно указываю на веб-сайт http://mywebsite.com,, я загружаю клиентскую часть, а с http://mywebsite.com/admin я загружаю административную часть с экраном входа в систему.

Моя проблема в том, что если я скомпилирую приложение с этими командами, все будет работать правильно:
ng build или ng serve
в то время как когда я собираю его для производства, он не работает: 

ng build --prod

У меня сейчас два вопроса: это угловая ошибка? Надежно ли начинать производство просто с помощью команды ng build вместо ng build --prod? Я тестировал с ng build (в производстве) и все работает нормально.

Ах, одно: во время компиляции появляется следующее предупреждение:

ПРЕДУПРЕЖДЕНИЕ в Обнаружении Ленивых маршрутов не включено. Потому что ни entryModule, ни статически анализируемый загрузочный код в основной файл.

1 Ответ

1 голос
/ 05 апреля 2019

Это не ошибка.Когда вы запускаете ng build --prod, вы запускаете его с включенной AOT компиляцией.Это означает, что приложение компилируется перед сборкой, чтобы убедиться, что все установлено правильноПохоже, что вы загружаете разные модули при загрузке приложения, и я не уверен, что компиляция AOT согласится с этим.Вы можете перейти на использование Ленивые загруженные модули и разделить свои приложения на 2 разных модуля.

Если вы действительно хотите, то попробуйте ng build --prod --aot=false или ng build --prod --aot false.

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

Проверьте Nrwl/Nx для Angular Здесь они предоставляют отличные инструменты для этого.Он поддерживает угловые вычисления, используя схемы.Я думаю, это вам очень поможет.может быть, вам нужно будет развернуть свои приложения в разных местах или использовать несколько разных сред для использования в каждом приложении, и этот monorepo идеально подходит для достижения этого ИМХО.

Подробнее о monorepos из Википедия :

Преимущества Монорепо имеет ряд потенциальных преимуществ перед отдельными хранилищами:

  • Простота повторного использования кода - аналогичные функциональные возможности или протоколы связи можно абстрагировать в общие библиотеки и напрямую включать в проекты без необходимости использования менеджера пакетов зависимостей.
  • Упрощенное управление зависимостями -В среде с несколькими репозиториями, где несколько проектов зависят от сторонней зависимости, эта зависимость может загружаться или создаваться несколько раз.В monorepo сборка может быть легко оптимизирована, так как все ссылочные зависимости существуют в одной кодовой базе.
  • Атомная фиксация - Когда проекты, которые работают вместе, содержатся в отдельных репозиториях, выпуски должны синхронизировать, какие версии одного проекта работают с другим.И в достаточно больших проектах управление совместимыми версиями между зависимостями может стать адом зависимости. [5]В monorepo эту проблему можно устранить, поскольку разработчики могут атомарно изменять несколько проектов.
  • Масштабный рефакторинг кода - Поскольку разработчики имеют доступ ко всему проекту, рефакторинг может гарантировать, что каждый компонентпроекта продолжает функционировать после рефакторинга.
  • Сотрудничество между командами - В монорепорте, использующем исходные зависимости (зависимости, скомпилированные из исходного кода), команды могут улучшить проекты, над которыми работают другие команды.Это приводит к гибкому владению кодом.

Ограничения и недостатки

  • Потеря информации о версии - Хотя это и не требуется, в некоторых сборках monorepo используется один номер версиивсе проекты в репозитории.Это приводит к потере семантического контроля версий для каждого проекта.
  • Отсутствие защиты для каждого проекта - При использовании разделенных репозиториев доступ к репозиторию может быть предоставлен в зависимости от необходимости.Monorepo предоставляет доступ для чтения ко всему программному обеспечению в проекте, возможно, представляет новые проблемы безопасности.

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

...