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).