Ability to set the default value of `standalone`

[anhallbe]

Which @angular/* package(s) are relevant/related to the feature request?

core

Description

In this blog post it is communicated that the value for standalone will default to true in version 19.

This will likely break our application that depends on being able to dynamically loading external components. Most of these external components were not developed with standalone in mind, so they have relied on the implicit standalone: false up until now.

The components are loaded by:

1. Import https://cdn-url/the-component.js
2. the-component.js exports a @Component and an optional @NgModule
3. Instantiate/compile the module with createNgModule() (unless the component is standalone)
4. Instantiate/compile the component with ViewContainerRef.createComponent

After version 19, I'm assuming that the ViewContainerRef.createComponent or the createNgModule calls will fail, since the component now implicitly has standalone: true, but it is also declared in the @NgModule and has no imports.

Proposed solution

Perhaps one of:

• Add an option to either createNgModule or createComponent where the default value can be overridden.
• Allow standalone components to be part of a NgModule declarations array, and make them inherit the NgModule imports or something.

This is all based on a lot of assumptions since as far as I can tell the new default isn't implemented yet. So I'm not sure what a good solution looks like (or even if one is needed).

Alternatives considered

None yet

[JeanMeche]

Hi,
How is the-component.js generated ? Are the components compiled ahead of time ? or do you rely on the JIT compiler ?

Libraries built againt angular v18 for example will work fine on v19 apps. This is because components are compiled (partially or full) when generating the library. At this time the internal standalone flag will be set. So a v18 component without standalone: true will still be considered a NgModule component in a v19 app.

[anhallbe]

Hi @JeanMeche! The components are only compiled with TypeScript at build-time, so we rely on JIT when loading them into the application. Think of it like a plugin system where these components (or "widgets") are developed and deployed completely separate from the rest of the app.

Will JIT-compiled components be handled similarly to libraries?

Here's what the-component.js might look like:

System.register(['tslib', '@angular/core'], (function (exports) {
        'use strict';
        var __decorate, Component, NgModule;
        return {
                setters: [function (module) {
                        __decorate = module.__decorate;
                }, function (module) {
                        Component = module.Component;
                        NgModule = module.NgModule;
                }],
                execute: (function () {

                        exports("factory", factory);

                        let TheComponent = class TheComponent {
                            constructor() {
                                this.title = "Hello, world!";
                            }
                        };
                        TheComponent = __decorate([
                            Component({
                                template: ` <p>{{ title }}</p> `,
                            })
                        ], TheComponent);
                        let TheModule = class TheModule {
                        };
                        TheModule = __decorate([
                            NgModule({
                                declarations: [TheComponent],
                            })
                        ], TheModule);
                        function factory() {
                            return {
                                componentType: TheComponent,
                                moduleType: TheModule,
                            };
                        }

                })
        };
}));

[JoostK]

Although JIT compilation in production is highly discouraged, this will indeed break under Angular 19.

The slightly better approach would be to compile the "remote" apps using partial compilation, which is a more complete compilation output that captures all details that are currently omitted (e.g. it contains the Angular version the component is compiled with, such that the runtime can act accordingly). This would still be relying on JIT compilation though, so even this is still not recommended.

I don't think we'd want to have some sort of configuration option for this, but I'll bring this up for discussion.

[JeanMeche]

Having an explicit standalone:true (for standalone components) or standalone:false (for module based components) for every directive/pipe should be an acceptable for around for this, wdyt ?

[JeanMeche]

Note: The migration schematic will be able to do it for you in the next pre-release (scheduled mid-week).

with ng update @angular/core --name explicit-standalone-flag

[JoostK]

Yeah, I believe the correct way to go about this is to redeploy the apps after having run the migration to introduce standalone: false everywhere it's currently missing. JIT compiled components are bound to reflect any defaults as determined by the runtime version. Partial compilation can be used to mitigate this a bit, but the dependency on the JIT compiler continues to be recommended against.

[anhallbe]

I know JIT is discouraged, and I wish we'd been able to move away from it. The problem for our part is that we need to guarantee that we can still load "old" components into newer Angular versions. I'm aware that Angular does not technically provide such guarantees, but JIT has allowed us to do it for almost a decade (minus that one time @ViewChild changed back in 9.0).

I don't know how others do it, and I know this might be a bit of an extreme edge case. But I'm sure this will affect others in a similar situation.

We can probably figure something out on our end, either through some extra browser-side transpilation step or maybe a "Angular Compiler and migration runner as a Service" thingy 🫨.

Anyway, I just wanted to provide some more details that may or may not be useful for the discussion.

[anhallbe]

I think I may have a workaround. It's not pretty, but I think this'll do the trick?

unStandalone(TheModule);

function unStandalone(cls: any) {
	if (isComponent(cls)) {
		cls.ɵcmp.standalone = false;
	} else if (isPipe(cls)) {
		cls.ɵpipe.standalone = false;
	} else if (isDirective(cls)) {
		cls.ɵdir.standalone = false;
	} else if (isNgModule(cls)) {
		for (const declaration of cls.ɵmod.declarations ?? []) {
			unStandalone(declaration);
		}
		// TODO: imports
	}
}

function isNgModule(cls: any): cls is { ɵmod: NgModule } {
	return cls.ɵmod !== undefined;
}

function isComponent(cls: any): cls is { ɵcmp: Component } {
	return cls.ɵcmp !== undefined;
}

function isDirective(cls: any): cls is { ɵdir: Directive } {
	return cls.ɵdir !== undefined;
}

function isPipe(cls: any): cls is { ɵpipe: Pipe } {
	return cls.ɵpipe !== undefined;
}

[JoostK]

I think I may have a workaround. It's not pretty, but I think this'll do the trick?

unStandalone(TheModule);

function unStandalone(cls: any) {
	if (isComponent(cls)) {
		cls.ɵcmp.standalone = false;
	} else if (isPipe(cls)) {
		cls.ɵpipe.standalone = false;
	} else if (isDirective(cls)) {
		cls.ɵdir.standalone = false;
	} else if (isNgModule(cls)) {
		for (const declaration of cls.ɵmod.declarations ?? []) {
			unStandalone(declaration);
		}
		// TODO: imports
	}
}

function isNgModule(cls: any): cls is { ɵmod: NgModule } {
	return cls.ɵmod !== undefined;
}

function isComponent(cls: any): cls is { ɵcmp: Component } {
	return cls.ɵcmp !== undefined;
}

function isDirective(cls: any): cls is { ɵdir: Directive } {
	return cls.ɵdir !== undefined;
}

function isPipe(cls: any): cls is { ɵpipe: Pipe } {
	return cls.ɵpipe !== undefined;
}

I doubt this will work, as the definition has already been compiled and may therefore already have reflected aspects of the standalone flag, such that changing it could result in inconsistencies.

I suppose it would be much easier to just patch the runtime code to change the default back. (I am not recommending that you should do that, but at least it's a possibility)

[JoostK]

We discussed this a bit more and the way to resolve this is to run the migration that will be available with v19. Depending on JIT'ing components means that you have to play by its compiler version rules.