角度应用程序上的多个根模块 [英] Multiple root modules on angular application
问题描述
我正在用 Angular 开发一个网站.这个应用程序分为两部分:客户端部分和管理员部分.后者可通过登录屏幕访问.这个机制的核心就是用这两个文件完成的:
I am developing a website in Angular. This app is divided into two parts: the client's part and the administrator's part. The latter is accessible via a login screen. The core of this mechanism is done with these two files:
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:
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 我用登录屏幕加载管理部分.
Basically if I point to the website normally http://mywebsite.com, I will upload the client part, while with http://mywebsite.com/admin I load the administration part with the login screen.
我的问题是，如果我使用这些命令编译应用程序，一切正常:ng build 或 ng serve
当我编译它用于生产时它不起作用:
My problem is that if I compile the app with these commands everything works correctly:
ng build or ng serve
while when I compile it for production it doesn't work:
ng build --prod
我现在有两个问题:这是一个角度错误吗?仅使用 ng build 而不是 ng build --prod 命令进入生产环境是否可靠?我已经用 ng build(生产中)测试过，一切正常.
I've two questions now: is this an angular bug? Is it reliable to go into production simply with the ng build instead the ng build --prod command? I've tested with ng build (in production) and all works fine.
啊，有一件事:在编译期间出现以下警告:
Ah, one thing: during compilation the following warning appear:
延迟路由发现中的警告未启用.因为有既不是 entryModule 也不是静态可分析的引导程序代码主文件.
WARNING in Lazy routes discovery is not enabled. Because there is neither an entryModule nor a statically analyzable bootstrap code in the main file.
推荐答案
这不是错误.当您运行 ng build --prod 时，您使用 AOT 运行它编译上.这意味着它在构建之前编译应用程序以确保一切设置正确.似乎您在引导应用程序时加载了不同的模块，我不确定 AOT 编译是否会同意这一点.您可以更改为使用延迟加载模块，并将您的应用分成 2 个不同的模块.
This is not a bug. When you run ng build --prod you run it with AOT compilation on. It means it compiles the app before the build to make sure everything set correctly. It seems like you are loading different Modules while bootstrapping your app and I'm not sure AOT compilation will agree to that. You can change to use Lazy Loaded modules and separate your apps to 2 different modules.
如果您真的想要，请尝试 ng build --prod --aot=false 或 ng build --prod --aot false.
If you really want then try ng build --prod --aot=false or ng build --prod --aot false.
由于它看起来像一个扩展应用程序，我认为对您来说最好的解决方案是使用 MonoRepo 模式.您将拥有多个带有库的应用程序，它们都将位于同一个项目下.您可以利用很多可重用性，并且维护会更容易.
Since it seems like a scaling application, I think the best solution for you will be to use MonoRepo patterns. you'll have multiple apps with libraries and they both will sit under the same project. You could leverage a lot of re-usability and maintenance will be easier.
检查 Nrwl/Nx 的 Angular 这里为此提供了很好的工具.它通过使用原理图支持 angular cli.我认为这会对你有很大帮助.也许您需要将您的应用部署到不同的地方，或者需要为每个应用使用一些不同的环境，而这个 monorepo 非常适合实现恕我直言.
Check Nrwl/Nx for Angular Here they provide great tooling for this. It supports angular cli by using schematics. I think it will help you a lot. maybe you would need to deploy your apps to different places or having some different environments to use for each app, and this monorepo is a perfect fit to achieve that IMHO.
来自 维基百科的关于 monorepos 的更多信息:
More about monorepos from Wikipedia:
优势 单体仓库有许多潜在优势通过单个存储库:
- 易于代码重用 – 类似的功能或通信协议可以抽象为共享库并直接包含在项目，无需依赖包管理器.
- 简化的依赖管理 – 在多存储库环境中多个项目依赖于第三方依赖项，该依赖项可能会被多次下载或构建.在 monorepo 中构建可以很容易地优化，因为引用的依赖都存在于相同的代码库.
- 原子提交 – 当一起工作的项目包含在单独的存储库中，发布需要同步哪些一个项目的版本与另一个一起工作.而且足够大项目，管理依赖项之间的兼容版本可以成为依赖地狱. [5]在 monorepo 中，这个问题可以被否定，因为开发人员可以原子地更改多个项目.
- 大规模代码重构 – 由于开发人员可以访问整个项目，因此重构可以确保项目的每一部分继续重构后的函数.
- 跨团队协作 – 在单一仓库中使用源依赖项(从源)，团队可以改进其他团队正在处理的项目.这导致灵活的代码所有权.
- Ease of code reuse – Similar functionality or communication protocols can be abstracted into shared libraries and directly included by projects, without the need of a dependency package manager.
- Simplified dependency management – In a multiple repository environment where multiple projects depend on a third-party dependency, that dependency might be downloaded or built multiple times. In a monorepo the build can be easily optimized, as referenced dependencies all exist in the same codebase.
- Atomic commits – When projects that work together are contained in separate repositories, releases need to sync which versions of one project work with the other. And in large enough projects, managing compatible versions between dependencies can become dependency hell.[5] In a monorepo this problem can be negated, since developers may change multiple projects atomically.
- Large-scale code refactoring – Since developers have access to the entire project, refactors can ensure that every piece of the project continues to function after a refactor.
- Collaboration across teams – In a monorepo that uses source dependencies (dependencies that are compiled from source), teams can improve projects being worked on by other teams. This leads to flexible code ownership.
限制和缺点
- 版本信息丢失 – 虽然不是必需的，但一些 monorepo构建在存储库中的所有项目中使用一个版本号.这会导致每个项目的语义版本丢失.
- 缺乏每个项目的安全性 – 使用拆分存储库，访问存储库可以根据需要授予.monorepo 允许读取所有项目中的软件，可能会带来新的安全问题.
- Loss of version information – Although not required, some monorepo builds use one version number across all projects in the repository. This leads to a loss of per-project semantic versioning.
- Lack of per-project security – With split repositories, access to a repository can be granted based upon need. A monorepo allows read access to all software in the project, possibly presenting new security issues.
希望对你有帮助
这篇关于角度应用程序上的多个根模块的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
