Search code examples
angularproduction

Multiple root modules on angular application

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:

<!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>

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.

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

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:

WARNING in Lazy routes discovery is not enabled. Because there is neither an entryModule nor a statically analyzable bootstrap code in the main file.

Solution

  • 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.

    If you really want then try ng build --prod --aot=false or ng build --prod --aot false.

    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.

    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.

    More about monorepos from Wikipedia:

    Advantages There are a number of potential advantages to a monorepo over individual repositories:

    • 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.

    Limitations and disadvantages

    • 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.

    Hope it'll help you