Angular component library AOT

Angular component libraries don’t ship with AOT “ngfactory” output. Why not?

Angular 2-and-up (I’m working with the version 4 release candidate at the moment) is a relatively large and complex single page app framework/library, but unlike some of its smaller competitors it has a key feature to mitigate this and provide a performance boost in deployment.

The feature is “ahead of time compilation”. With AOT, HTML templates used by an application are parsed/compiled during the build process, rather than when they are used in the running application on a web page. This compilation converts the textual templates to TypeScript classes, which are then bundled along with human-written application code. As a result, with AOT large portions of the Angular framework can be excluded from the deployed application.

AOT is typically performed with a command line program “ngc”, in an application build process.

But what about libraries of pre-built Angular components? Should a component library (which might be published as a NPM package, or by some other means) include this AOT output, which takes the form of “*.ngfactory.ts” files?

No – Angular itself does not work this way and build tooling does not support or encourage such a thing. If it did encourage bundling the AOT output libraries:

  • Libraries would not benefit from further improvements to AOT, without also releasing out a new version of the package.
  • AOT would need to generate code which works across version skew, in order to respect semver. this would be a frequent and problematic restriction.

The actual implementation of AOT expects AOT to be performed always at a project level and never at a library level (although the letter is not exactly true; you may use the AOT tool in the library to produce “metadata” files).  With this design, you can consume a library written (for example) with Angular 2.3.3, even if your project is using Angular 2.4.5 (somewhat different AOT output) or Angular 4.x (very different AOT output).