ngx-planet runs several Angular apps inside one portal shell

What the library does for an Angular monorepo of apps

ngx-planet describes itself as a micro frontend library for Angular, with APIs consistent with angular style, and it says plainly that it currently only supports Angular and that other frameworks are not supported. The feature list is the interesting part. It renders multiple applications at the same time. It supports two modes, coexist and default, where one switches to another app and destroys the active apps. It supports application preload, style isolation, built-in communication between multiple applications, cross application component rendering, and examples covering routing configuration, lazy loading and all of the features. The audience is therefore a team that has decided to split one Angular front end into several independently built and deployed applications and needs a portal shell to host them. The homepage is planet.ngnice.com, and there is a live demo at planet-examples.ngnice.com, along with documentation sections for the introduction, getting started, development and build, data shared and communication, cross application component rendering and the API reference.

Installing and loading the module in the portal

The package is published to npm under the scoped name @worktile/planet.

$ npm i @worktile/planet --save
// or
$ yarn add @worktile/planet

The first step in the portal is to import the module, which is a single NgModule import in the portal's own AppModule.

import { NgxPlanetModule } from '@worktile/planet';

@NgModule({
  imports: [
    CommonModule,
    NgxPlanetModule
  ]
})
class AppModule {}

The repository also carries a Chinese-language README, and the documentation site is the primary reference. The build tooling around it is worth noting for anyone planning a CI setup: the package.json declares engines for node at ^22.22.3, ^24.15.0 or 26 and above, npm at 7.0.0 or above, and it asks you to use npm rather than yarn to install dependencies. The examples directory contains app1, app2, common, portal and standalone-app projects, and the scripts run the portal and the sub-apps together under webpack dev-server with per-app serve paths under /static.

Registering applications and how the portal finds them

Registration happens through the Planet service, which the portal component injects. You set options such as the switch mode and an error handler, then call registerApps with a list of application descriptors, and finally call start. Each descriptor carries a name, the hostParent element selector the app renders into, a hostClass for the host element, a routerPathPrefix used to match the route to the app, a preload flag, and an entry. The entry is either a string pointing at the index.html, or an object with a basePath, a manifest, and explicit scripts and styles lists. The README's own comments describe the sequence the library performs at start: monitor route changes, get the apps to activate by the current path, load the static resources which contain javascript and css, bootstrap the angular sub app module and show it. The basePath matters because every resource request is prefixed with it, which is what lets several apps coexist under one host path.

How a sub application declares its own bootstrap

Each sub application has to describe how to start itself, because the portal cannot know the sub app's module shape. For a standalone application, which the README marks as supported from 17.0.0 upwards, the declaration supplies a template and a bootstrap function that receives the portal application.

defineApplication('standalone-app', {
    template: `<standalone-app-root></standalone-app-root>`,
    bootstrap: (portalApp: PlanetPortalApplication) => {
        return bootstrapApplication(AppRootComponent, {
            providers: [
                {
                    provide: PlanetPortalApplication,
                    useValue: portalApp
                },
                {
                    provide: AppRootContext,
                    useValue: portalApp.data.appRootContext
                }
            ]
        }).catch(error => {
            console.error(error);
            return null;
        });
    }
});

Two providers are injected into the sub app, PlanetPortalApplication which carries the portal's own application reference, and AppRootContext which carries portalApp.data.appRootContext. That second provider is the mechanism by which the sub app receives whatever context the portal decided to hand down, and it is the same shape used in the NgModule variant, which instead calls platformBrowserDynamic and bootstrapModule. The NgModule path resolves to the app module and returns it, while the standalone path resolves through bootstrapApplication. Both swallow errors into a console.error and return null, so a failed bootstrap does not take down the portal, though it also does not report anything more useful than a console message.

The configuration table, and one option that is on its way out

The README documents the sub app configuration fields in a table. The name is the application's name. The routerPathPrefix is the application route path prefix, and the app is matched on it. The selector is the selector of the app root component, and the explanation of why it exists is worth reading, because it reveals an implementation detail: the sub app is dynamically loaded by the main app, so the main app has to create the selector node first and then start the AppModule. The entry field is either a string or a PlanetApplicationEntry object, containing the manifest, scripts and styles, where a string means the app entry is index.html, and in the object case the manifest is the entry html or json file address, scripts and styles are the specified resource lists, and if they are not specified all resources returned by the manifest interface are used. The manifest field on its own is a separate option and it is marked deprecated, with a note to use entry instead. That is a small but useful signal about where the API is heading, and it is the kind of detail that saves an upgrade later.

Switching modes, style isolation and the built-in communication channel

The two switching modes are the behavioural core of the library. In coexist mode more than one application is active at once, which suits a portal where a shell and a sub-application both need to be on screen. In default mode, switching to another app destroys the apps that were active, which suits a product where exactly one area of the interface is live at a time. The registration example in the README uses coexist with an error handler that logs a failure to load a resource, so a broken sub app does not take the portal with it. Style isolation matters more than it sounds in an Angular micro frontend setup, because each app brings its own styles and the global scope of an Angular application does not stop at the host element in the way you might hope. Built-in communication between applications and cross application component rendering extend the same idea: a component from one app rendered inside another app's tree, which is the part that makes this a framework rather than a routing helper, and the part that carries the most integration risk.

Where ngx-planet is the wrong choice

The Angular-only constraint is the first one, and the README does not soften it. A portal that has to host a React app, a Vue app and an Angular app gets nothing here, and the alternative listed in the README is single-spa, which is described as a javascript front-end framework that supports any frameworks. The second alternative mentioned is mooa, an independent-deployment micro-frontend Framework for Angular derived from single-spa, and the README's comparison is that planet is very similar to it but is described as more capable, more reliable, more productive and more Angular. That is a claim rather than evidence, so it is worth reading mooa's documentation yourself before ruling it out. The second limit is version drift, and it is visible in the repository. The recent releases list shows 17.0.0 from 2024-03-18, 15.0.0 from 2023-03-09 and 13.0.0 from 2022-05-16, while the package.json in the repository declares version 22.0.0. The last push was on 2026-10-20, so the code is being worked on, but the release history on GitHub stops in 2024. The third limit is that a micro frontend framework is a large architectural commitment. Splitting an Angular application into independently deployed pieces means the portal owns routing, shared state, styling boundaries and version compatibility across separately built bundles, and the examples in the repository show that the setup involves per-app build scripts, serve paths, base hrefs and an nginx image that assembles the pieces into static directories.

Editorial conclusion

Adopt ngx-planet if your organisation is already Angular-only and is splitting a large front end into independently deployed applications. Skip it if you have more than one framework in the estate, because the README states that other frameworks are not supported. Before you commit, check the published npm version against the repository's package.json, because the two disagree, and read the entry configuration carefully since the manifest option is marked deprecated in favour of entry.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. worktile/ngx-planet on GitHub