-
Notifications
You must be signed in to change notification settings - Fork 11.9k
Closed
Description
Command
build
Description
The new experimental buildApplicationInternal function has a very flexible API. Its support for passing multiple entry points is especially interesting.
Scenario: I'm building a regular old website (MPA), documentation for a component library. There are over 100 components, with each multiple examples that I'd like to run live on the site.
The documentation site is not an Angular SPA, but set up via a "markdown -> static site" generator (mdbook).
Describe the solution you'd like
Expose the internal application builder function, allowing me to build the entire documentation with multiple entry-points—each with its own bootstrap—in one go.
export default createBuilder((input, context) =>
buildApplicationInternal( // <-- using internal import here
{
watch: false,
progress: false,
index: false,
entryPoints: collectEntryPoints(context),
// more options
},
context,
),
);Describe alternatives you've considered
Past solutions for our documentation:
- Make the documentation a regular angular app. That's how we started out, turns out no one likes writing documentation like this.
- Copy the aio setup from angular/angular and make our own "markdown pages -> angular app" pipeline. Tried that, but the setup of aio is… not the easiest to understand or maintain if you're not used to it.
- Use storybook. That's where we're currently at.
Alternatives to exposing the internal application builder function:
- Build every page into a separate angular app. This makes the build prohibitively slow.
- Build a single angular app with bootstraps for every documentation page. This would either load all code for all pages for any page, or it would require quite a lot of shenanigans to ensure we don't load all that superfluous javascript over a shabby internal corporate proxy server.
- Make the multiple entry points available in the existing experimental application builder's schema. For me this solution would work equally well, but I believe the use case (running angular in an MPA) to be so different from what a regular angular app looks like that adding the option will only lead to confusion for developers who just want to build SPAs.
- Make a separate "MPA application" builder. This puts the onus on the angular team to properly support building Angular MPAs, which I don't expect to align with the goals of the framework.
Reactions are currently unavailable