Skip to content

Expose internal application builder function #25556

@bgotink

Description

@bgotink

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:

  1. Make the documentation a regular angular app. That's how we started out, turns out no one likes writing documentation like this.
  2. 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.
  3. Use storybook. That's where we're currently at.

Alternatives to exposing the internal application builder function:

  1. Build every page into a separate angular app. This makes the build prohibitively slow.
  2. 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.
  3. 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.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions