Angular doesn't support custom decorators?

[aharl]

Recently saw this comment by an Angular team member. angular/angular#48276 (comment)

If this true that angular doesn't support custom decorators then what is the future of the current api in until-destroy?

I can confirm that the custom decorator broke existing applications I maintain when updating to Angular 15. Work arounds in tsconfig do remediate the problem as well.

[aharl]

Here is another longer comment clarifying the issue with custom decorators and AOT.

angular/angular-cli#20714 (comment)

[arturovt]

Can you provide a minimal reproducible example of what issue you're experiencing?

[aharl]

Here are copies of the relevant comments from the links I provided above.

---

Link to source: angular/angular#48276 (comment)

Angular doesn't support custom decorators on its component classes or other decorated members. Depending on what the decorator does, it may or may not function correctly.

We don't support them because there's a big conceptual mismatch - the Angular compiler is trying to statically transform classes according to their Angular annotations, but custom decorators are attempting to arbitrarily change the shape of that class at runtime.

---

Link to source: angular/angular-cli#20714 (comment)

The issue now is not the decorator as it is the removal of components not found in template or directly referenced from code.

This is called tree-shaking - the removal of code such as components that's not directly referenced by an application. It's a design goal of Angular that components which are not found in a template and not directly referenced in code are removed.

That is, if you write:

class Foo {...}

and your code never references Foo, the optimizer is free to remove Foo entirely from the built application bundle. That optimization is normal and desirable.

But, what happens if you have a decorated class?

@Decorator
class Foo {...}

Can the optimizer safely make the same decision? It depends on what @Decorator does:

if @Decorator only mutates Foo, and doesn't have any other effects, then clearly yes

• if @Decorator has some observable side effect, like making network requests, console.log'ing, or saving a reference to Foo somewhere (like a global REGISTRY), then arguably no.
• A major problem with this situation is that optimizers only analyze code, they don't execute it, so it's very difficult for them to tell the above two cases apart. Any function call inside the decorator may perform global operations like the ones above.

It's arguable that the intent of the decorator spec was to allow for the first case (mutating Foo only) and not for non-local effects, as per the language mentioned earlier:

Decorators should affect the thing they're decorating, and avoid confusing/non-local effects.

Angular is designed with this interpretation in mind, and the production optimization performed by our CLI relies on this interpretation of decorators.

This is, however, complicated by the fact that decorators are not currently supported in some browsers directly, and so they're downleveled by TypeScript into JavaScript code that uses TypeScript's __decorate helper function instead. This code is much harder for an optimizer like Terser to follow, so Angular built the build-optimizer transformation which restructures downleveled decorators into a form that doesn't appear to the optimizer as globally side-effectful.

Disabling build-optimizer is a workaround - it ensures that at least for the current downleveling that TypeScript does, the optimizer won't be able to understand the form of decorated classes and will be forced to retain them. This is not guaranteed to work forever, but it does today.

build-optimizer could conceivably allow exclusion of particular libraries, and you should feel free to argue for that as a feature request. I don't think the case for such a feature is substantially compelling, however, because there are far better and more idiomatic Angular patterns for registering components into an index of some kind, which don't require global side effects.

For example, using a registry service that's injected into NgModule constructors and performing the registration there, or using a multi: true provider and DI. The idea here is that registration depends on a direct reference from the application (including the library's NgModule in your AppModule), and doesn't happen just because the library code happens to be included in the build.

[NetanelBasal]

I'd not worry about it. As @arturovt said, this library has worked for years and is used in many production environments, so no worries.

[aharl]

Look I'm not saying that you are wrong but I'm definitely concerned about this since this broke several enterprise applications that we use your library in as we updated to Angular 15. Caveat emptor.

As I mentioned above I will get a working example prepared for you to take a look at.

[arturovt]

@aharl I don't think it makes sense to waste our time and ping us in this discussion because we're wasting time talking about "a cat in a poke". Make a working example where your code fails because of our decorator. We'll have a look and try to provide a working solution as soon as possible since we're responsible for the API reliability. Cheers.

[aharl]

Please feel free to mark this discussion 'answered' if you prefer, since I think your stance on my initial question is clear. I'll raise an issue when I have time.