Dav*_*ide 5 production angular
我正在用 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);
}
索引.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 也没有静态可分析的引导程序代码。
这不是一个错误。当你运行时，你会在AOTng build --prod编译开启的情况下运行它。这意味着它会在构建之前编译应用程序，以确保一切设置正确。看起来您在引导应用程序时正在加载不同的模块，我不确定 AOT 编译是否会同意这一点。您可以更改为使用延迟加载模块，并将您的应用程序分为 2 个不同的模块。
如果你真的想要那么尝试ng build --prod --aot=false或ng build --prod --aot false。
由于它看起来像一个扩展应用程序，我认为对您来说最好的解决方案是使用 MonoRepo 模式。您将拥有多个带有库的应用程序，并且它们都将位于同一个项目下。您可以充分利用可重用性，并且维护会更容易。
\n\n检查Nrwl/Nx这里Angular ，他们为此提供了很好的工具。它通过使用原理图支持 Angular cli。我认为这会对你有很大帮助。也许您需要将应用程序部署到不同的地方，或者为每个应用程序使用一些不同的环境，而这个 monorepo 非常适合实现这一目标。
更多关于Wikipedia中的 monorepos 的信息：
\n\n\n\n\n优点 与单个存储库相比，单一 存储库有许多潜在的优势：
\n\n\n
\n\n- 易于代码重用\xe2\x80\x93 类似的功能或通信协议\n 可以抽象为共享库并直接包含在\n 项目中，而不需要依赖包管理器。
\n- 简化的依赖项管理\xe2\x80\x93 在多个存储库环境中，\n 多个项目依赖于第三方依赖项，该依赖项\n 可能会被下载或构建多次。在单一存储库中，可以轻松优化构建，因为引用的依赖项都存在于同一代码库中。
\n- 原子提交\xe2\x80\x93 当协同工作的项目包含在单独的存储库中时，版本需要同步一个项目的哪些版本与另一个项目协同工作。在足够大的项目中，管理依赖项之间的兼容版本可能会成为依赖项地狱。[5] 在单一存储库中，这个问题可以得到解决，因为开发人员可以自动更改多个项目。
\n- 大规模代码重构\xe2\x80\x93 由于开发人员可以访问整个项目，重构可以确保项目的每个部分在重构后继续运行。
\n- 跨团队协作\xe2\x80\x93 在使用源依赖项（从源编译的依赖项）的单一存储库中，团队可以改进其他团队正在处理的项目。\n 这会带来灵活的代码所有权。
\n局限性和缺点
\n\n\n
\n- 版本信息丢失\xe2\x80\x93 尽管不是必需的，但某些 monorepo\n 构建在存储库中的所有项目中使用一个版本号。\n 这会导致每个项目语义版本控制的丢失。
\n- 缺乏每个项目的安全性\xe2\x80\x93 通过拆分存储库，可以根据需要授予对存储库的访问\n 权限。monorepo 允许对项目中的所有软件进行读取访问，这可能会带来新的安全问题。
\n
希望它能帮助你
\n| 归档时间： |
|
| 查看次数： |
3998 次 |
| 最近记录： |