Provide options to enable/disable the removal of decorators and replacement of resources in a prod build with AOT

This is a feature request referring to the prod build with AOT using the CLI. A more general title would be “Provide options to make the applied transformations configurable”. For my use case, it is sufficient to just consider the two specific options described below - but other developers might have other use-cases.

Requirements

It would be very helpful to me and many other developers if the compiler options would provide means to control the removal of decorators in a prod build with AOT. There are two ways that could make it happen. Either in tsconfig.json as a parameter to angularCompilerOptions, e.g.:

  "angularCompilerOptions": {
    "aotRemoveDecorators": false
  }

Or as a switch to the ng-command, e.g.

ng build --prod --aotRemoveDecorators=false

The wording of such an option is yet to be discussed. I personally would favor to distinguish options that are only valid for either AOT or JIT by having a prefix/suffix in the option’s name as indicated.

Additional Requirement

For the use-case described below, it is also important to replace style and template URLs by their content. This is what is done in JIT mode just a few lines above the referenced code (see link below). Now either the proposed option implies this behavior (which I don’t like since it is not obvious) or another option gives the developer control for that behavior, too, e.g.

ng build --prod --aotRemoveDecorators=false --aotReplaceResources=true

Use-Case

There are Angular apps that use standard Angular means. To make those applications run fast, it makes sense to use AOT. However, many of those applications also have a need to build Angular components dynamically and invoke the JIT compiler. I am aware that it seems unusual to use JIT and AOT in one app, but it is also a reality that many applications have this need (just do a search for AOT and JIT in the angular github issues). It has also been shown that it is indeed possible to make AOT and JIT work together (e.g. see https://github.com/angular/angular/issues/15510). However, since the CLI removes the decorators in a prod build, the JIT compiler cannot compile the components and is emitting errors like “Please add a @NgModule annotation”.

To make it work nowadays, it requires to hand-craft the build yourself using webpack or another bundler, but it is much more complex. Instead, it would be much more convenient to rely on the Angular CLI and use the powerful ecosystem that the CLI provides. The cost of adding such an option seems to me negligible compared to the pain many developers have. And I would highly appreciate if the CLI team would consider it.

The code responsible for the removal

The code responsible for the removal is located here: https://github.com/angular/angular-cli/blob/5f73a75193bc1217cbfb7f2240355679517cc8d0/packages/%40ngtools/webpack/src/angular_compiler_plugin.ts#L682

Workarounds

I don’t know any workaround and I would be very happy to hear some. For example, I was wondering if it is possible to override the function “removeDecorators” to just do nothing? Any other ideas?

[lefoulkrod]

@robwormald As others have expressed, there are companies (like mine) that want to use Angular but have use cases which would be very well served by being able to dynamically compile an html template into a component at runtime, knowing the risks and performance implications. You may want to reconsider this as a valid use case.

[Paladinium]

Thanks, @robwormald for taking your time to explain the thoughts of the Angular team on that subject. I do acknowledge many of your points (security, bundle size, performance, …).

On the other side, I would be very happy if the Angular team could start to honor the need for more dynamic applications. The changes you mentioned for Angular 7 seem to go into that direction. But I am convinced that for web apps with an adaptive UI (e.g. allowing its customers for configuration), a very dynamic solution is required. This could also be a significant differentiator to other web frameworks.