Class Decorator prevents tree-shaking

[fischeversenker]

Command

build

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

A library component with a (non-Angular) decorator will not be tree-shaken. The same component, if inside an app, will be properly tree-shaken.

There is a history of issues related to this topic:

• ES2015 Class with decorators are not being treeshaken away #14610
  This matches the topic exactly. According to the issue and the linked PR this might be a regression
• Custom decorators not working using AoT #20714 (comment) (links to a comment)
  This seems to say that all decorators are always assumed to be side-effect free, but it looks like this is not the case anymore
• unused classes got added in build, tree-shaking not working propely #15396 (comment) (links to a comment)
  There seemed to be a problem with custom libraries, but in my repro everything comes straight from the angular-cli
• File / class deleted during tree shake despite the fact it's being used #16246 (comment) (links to a comment)
  This also sounds like this was fixed in the past, hinting yet again that this might be a regression

Minimal Reproduction

Reproduction repository: https://github.com/fischeversenker/ng-decorator-tree-shaking/tree/274524fde27002e87f1535ef6bbef2cf8088ec8d

The essence:

This library code:

import { Component } from '@angular/core';

/*@__PURE__*/
function noopDecoratorFactory() {
  return /*@__PURE__*/ (target: any) => target;
}

@noopDecoratorFactory()
@Component({
  selector: 'lib-my-library',
  template: `my-library works!`
})
export class MyLibraryComponent {}

turns into this:

let MyLibraryComponent = class MyLibraryComponent {
};
// ...
MyLibraryComponent = __decorate([
    noopDecoratorFactory()
], MyLibraryComponent);

which seems to not be tree-shakeable.

Exception or Error

No response

Your Environment

Angular CLI: 14.2.6
Node: 16.16.0
Package Manager: yarn 1.22.19 
OS: linux x64

Angular: 14.2.7
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1402.6
@angular-devkit/build-angular   14.2.6
@angular-devkit/core            14.2.6
@angular-devkit/schematics      14.2.6
@angular/cli                    14.2.6
@schematics/angular             14.2.6
ng-packagr                      14.2.2
rxjs                            7.5.7
typescript                      4.7.4

Anything else relevant?

The real-life use case where this adds huge amounts of unused code to our bundles is when using https://github.com/ngneat/until-destroy#use-with-ivy in library components.

[clydin]

The behavior as described is expected. TypeScript's implementation of decorators causes a class to be referenced and, as a result, the class is then considered used from an optimizer's perspective. The Angular compiler avoids this problem by eliding Angular related decorators during the Ahead-of-Time compilation process.
The Angular CLI does have a pre-optimization pass designed to assist in situations where a decorated class should be tree-shaken. This pass requires that a JavaScript module be marked as side effect free to signal that the decorator usage does not cause any non-local side effects and is safe to be removed if the class is otherwise unused. This is different than an optimizer's use of the pure annotation which is used only to mark specific call expressions as having no side effects. Angular libraries should generally be marked at the package's root package.json as being side effect free via the "sideEffects": false field. Applications, however, must ensure not to mark files with non-local side effects to avoid application breakage (main.ts and polyfills.ts being primary examples).
For additional information regarding this from a library perspective but including links to additional documentation more relevant to configuring an application, please see https://angular.io/guide/angular-package-format#sideeffects-flag

[fischeversenker]

Thanks for the quick response, @clydin.

By adding "sideEffects": false to the library's package.json, the unused component is in fact tree-shaken 🎉

Why is this not added by default? Angular-CLI (I'm assuming ng-packagr) adds this flag to a library's "built" package.json, so it already automatically assumes that any Angular library is side-effect-free. Why is the same not true when importing from the source directly?
Also, the library in my reproduction repository got created with ng generate library .... Would you consider adding "sideEffects": false to the package.json template?

[alan-agius4]

Why is this not added by default? Angular-CLI (I'm assuming ng-packagr) adds this flag to a library's "built" package.json, so it already automatically assumes that any Angular library is side-effect-free. Why is the same not true when importing from the source directly?

Indeed the flag is added automatically by ng-packagr unless it's already specified.

When importing the source directly you effective no longer have a library in terms of a compilation unit and boundary rules. Rather an additional directory in the application with a nested package manifest file.

Overall, It is not recommended to build the library as part of the application either through path mapping or depending directly on the source file. This is also highlighted in the docs here: https://angular.io/guide/creating-libraries#building-and-rebuilding-your-library

The CLI build command uses a different builder and invokes a different build tool for libraries than it does for applications.

The build system for applications, @angular-devkit/build-angular, is based on webpack, and is included in all new Angular CLI projects

• The build system for libraries is based on ng-packagr. It is only added to your dependencies when you add a library using ng generate library my-lib.
• The two build systems support different things, and even where they support the same things, they do those things differently. This means that the TypeScript source can result in different JavaScript code in a built library than it would in a built application.

For this reason, an application that depends on a library should only use TypeScript path mappings that point to the built library. TypeScript path mappings should not point to the library source .ts files.

Other than the above, there might also be cases when consuming the so called "library" as described above could result in a slow build and increase in bundle size due to the fact that the "library" ESM modules are not flattened (FESMs).

Also, the library in my reproduction repository got created with ng generate library .... Would you consider adding "sideEffects": false to the package.json template?

I am okay with that. Although we do expect libraries to be built prior to being consumed in an application.

[alan-agius4]

Closing as working as expected.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}