{"id":2439,"date":"2017-06-03T11:19:32","date_gmt":"2017-06-03T09:19:32","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=2439"},"modified":"2017-06-03T11:19:32","modified_gmt":"2017-06-03T09:19:32","slug":"shrinking-angular-bundles-with-closure","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/shrinking-angular-bundles-with-closure\/","title":{"rendered":"Shrinking Angular Bundles With Closure"},"content":{"rendered":"
\n

\nBig thanks to Alex Eagle<\/a> from the Angular Team and to Carmen Popoviciu<\/a> for reviewing this post.\n<\/p><\/blockquote>\n

Closure is said to be the most sophisticated JavaScript compiler available today. Its advanced optimization mode goes far beyond the tree shaking capabilities of other tools and allows for shrinking bundles to a minimum. Google uses it to improve the performance of its own products like Google Docs and even Microsoft is using it meanwhile for Office 365. However, it's considered to be an expert tool and therefore difficult to configure. In addition to that, it assumes that the underlying JavaScript code has been written in a specific way.<\/p>\n

Currently, the Angular team is working hard on making Angular work together with Closure<\/a> as well as with its build tool Bazel. There are some first examples available, e. g. the Example<\/a> Alex Eagle<\/a> from the Angular Team created.<\/p>\n

This post uses the mentioned example to show how to use the Closure compiler as well as the advantages it brings regarding bundle sizes. Furthermore, this post explains how to add own and existing packages to a Closure based project.<\/p>\n

Building a base line with the Angular CLI<\/h2>\n

In order to create a baseline for comparing Closure with a 'traditional' build task for Angular, let's create a new Hello World application with the Angular CLI<\/a>:<\/p>\n

ng new baseline\ncd baseline\n<\/code><\/pre>\n
Now, let's create a production build:<\/p>\n
ng build --prod\n<\/code><\/pre>\n
The generated bundles have a size of about 394K:<\/p>\n
   1.460 inline.093de888567e5146835d.bundle.js\n   9.360 main.0d097609144c942cc763.bundle.js\n  60.845 polyfills.d90888e283bda7f009a0.bundle.js\n 322.320 vendor.765bef7fc0b73d2d51d7.bundle.js\n\n         393.985 Bytes\n<\/code><\/pre>\n
As the Closure sample in the next sections is directly importing the zone.js polyfill and not importing any other ones, we should omit the polyfills bundle from this observation:<\/p>\n
   1.460 inline.093de888567e5146835d.bundle.js\n   9.360 main.0d097609144c942cc763.bundle.js\n 322.320 vendor.765bef7fc0b73d2d51d7.bundle.js\n\n         333.140 Bytes\n<\/code><\/pre>\n
This leaves about 333K.<\/p>\n
After this we are installing Angular Material as well as the Animation package which Angular Material depends on:<\/p>\n
npm i @angular\/material --save\nnpm i @angular\/animations --save\n<\/code><\/pre>\n
To import it into the application, its AppModule<\/code> is referencing some of Angular Material's Modules:<\/p>\n
import { BrowserModule } from '@angular\/platform-browser';\nimport { NgModule } from '@angular\/core';\nimport { FormsModule } from '@angular\/forms';\nimport { HttpModule } from '@angular\/http';\nimport { AppComponent } from '.\/app.component';\n\nimport { \n  MdButtonModule, \n  MdAutocompleteModule,\n  MdCheckboxModule,\n  MdDatepickerModule,\n  MdCardModule,\n  MdRadioModule,\n  MdChipsModule,\n  MdListModule,\n  MdSnackBarModule,\n  MdSliderModule,\n  MdDialogModule,\n  MdMenuModule,\n  MdSidenavModule\n} from '@angular\/material';\n\n@NgModule({\n  imports: [\n    BrowserModule,\n    FormsModule,\n    HttpModule,\n    MdButtonModule, \n    MdAutocompleteModule,\n    MdCheckboxModule,\n    MdDatepickerModule,\n    MdCardModule,\n    MdRadioModule,\n    MdChipsModule,\n    MdListModule,\n    MdSnackBarModule,\n    MdSliderModule,\n    MdDialogModule,\n    MdMenuModule,\n    MdSidenavModule\n  ],\n  declarations: [\n    AppComponent\n  ],\n  providers: [],\n  bootstrap: [AppComponent]\n})\nexport class AppModule { }\n<\/code><\/pre>\n
After recreating a production build (ng build --prod<\/code>) we see that it grew to about 951K:<\/p>\n
   1.460 inline.36030f130bb8b4d4d1e6.bundle.js\n 246.959 main.bd55167e3a85bc1edaab.bundle.js\n 702.496 vendor.9618c29d7fbb7af5a536.bundle.js\n      950.915 Bytes\n<\/code><\/pre>\n
As the bundle size increased even though we are not using the imported modules from Angular Material this shows that the CLI\/ webpack is not able to find this out and shake these modules off.<\/p>\n
Now let's see how the sample application can be optimized with Closure.<\/p>\n
Using the Closure Compiler<\/h2>\n
To get started with Angular and the Closure Compiler, I'm using Alex Eagle<\/a>'s example. For this, I've forked<\/a> the version available when writing this.<\/p>\n
I modified it to use npm instead of yarn and after running npm run build<\/code> I got a bundle with just about 106K:<\/p>\n
 105.934 bundle.js\n<\/code><\/pre>\n
This is an huge improvement over using the CLI with webpack which led to bundles with about 390K for a quite similar \"Hello-Word\"-App.<\/p>\n
In order to make a fair comparison, we also need to include the packages @angular\/forms<\/code> and @angular\/http<\/code> as these packages are also imported into the CLI based app:<\/p>\n
npm i @angular\/http --save\nnpm i @angular\/forms --save\n\n<\/code><\/pre>\n
In order to import them into the Angular App, the AppModule<\/code> has to reference them:<\/p>\n
import {NgModule} from '@angular\/core';\nimport {HttpModule} from '@angular\/http';\nimport {FormsModule} from '@angular\/forms';\nimport {BrowserModule} from '@angular\/platform-browser';\nimport {Basic} from '.\/basic';\n\n@NgModule({\n  declarations: [Basic],\n  bootstrap: [Basic],\n  imports: [BrowserModule, FormsModule, HttpModule],\n})\nexport class AppModule {\n}\n<\/code><\/pre>\n
Unfortunately, the Closure Compiler does not respect the conventions introduced by NodeJS and so it does not automatically search the folder node_modules<\/code> for these packages. Therefore, they have to be referenced explicitly within the file closure.conf<\/code>:<\/p>\n
node_modules\/@angular\/forms\/@angular\/forms.js\n--js_module_root=node_modules\/@angular\/forms\n\nnode_modules\/@angular\/http\/@angular\/http.js\n--js_module_root=node_modules\/@angular\/http\n<\/code><\/pre>\n
Those lines reference both, the path where the package is found as well as its entry point which is also the whole content of the package due do the use of the FESM15-Format<\/a>.<\/p>\n
After building everything again (npm run build<\/code>) we are ending up with about 125K:<\/p>\n
 125.134 bundle.js\n<\/code><\/pre>\n
This is still an huge improvement over using the CLI and\/or Webpack.<\/p>\n
\nPlease note that this example is using Closure's Advanced Mode. This mode provides better results as other known tools, but is also quite aggressive. That's why it can damage the generated bundle and so it's recommended to use this mode always together with good E2E testing.\n<\/p><\/blockquote>\n
Using Closure with an Angular Package through the example of Angular Material<\/h2>\n
Now let's go on and import Angular Material. Once again, we have to load the following packages:<\/p>\n
npm i @angular\/material --save\nnpm i @angular\/animations --save\n<\/code><\/pre>\n
And - of course - we have to import the same Angular Material Modules as before:<\/p>\n
import {NgModule} from '@angular\/core';\nimport {BrowserModule} from '@angular\/platform-browser';\nimport {Basic} from '.\/basic';\nimport { LibStarterModule } from 'stuff-lib';\nimport { HttpModule } from \"@angular\/http\";\nimport { FormsModule } from \"@angular\/forms\";\n\nimport { \n  MdButtonModule, \n  MdAutocompleteModule,\n  MdCheckboxModule,\n  MdDatepickerModule,\n  MdCardModule,\n  MdRadioModule,\n  MdChipsModule,\n  MdListModule,\n  MdSnackBarModule,\n  MdSliderModule,\n  MdDialogModule,\n  MdMenuModule,\n  MdSidenavModule\n} from '@angular\/material';\n\n@NgModule({\n  declarations: [Basic],\n  bootstrap: [Basic],\n  imports: [\n    BrowserModule, \n    HttpModule, \n    FormsModule, \n    MdButtonModule, \n    MdAutocompleteModule,\n    MdCheckboxModule,\n    MdDatepickerModule,\n    MdCardModule,\n    MdRadioModule,\n    MdChipsModule,\n    MdListModule,\n    MdSnackBarModule,\n    MdSliderModule,\n    MdDialogModule,\n    MdMenuModule,\n    MdSidenavModule\n  ],\n})\nexport class AppModule {\n}\n\n<\/code><\/pre>\n
In addition to that, it is also necessary to tell Closure about the imported modules. Therefore the closure.conf<\/code> gets the following additional lines:<\/p>\n
node_modules\/@angular\/animations\/@angular\/animations.js\n--js_module_root=node_modules\/@angular\/animations\n\nnode_modules\/@angular\/material\/@angular\/material.js\n--js_module_root=node_modules\/@angular\/material\n<\/code><\/pre>\n
Before we can create a build, we have to update the TypeScript Compiler, as the used version of the example comes with 2.1 while the current version of Angular Material needs 2.2+:<\/p>\n
npm uninstall typescript --save-dev\nnpm install typescript@^2.2 --save-dev\n<\/code><\/pre>\n
After creating another build our bundles has about 200K:<\/p>\n
199.970 bundle.js\n<\/code><\/pre>\n
This shows two things: First of all, using Closure brings a huge improvement over using the CLI and\/or webpack which led to a bundle with about 951K. But this experiment also shows that even Closure is not able to fully shake off the imported but unused Modules.<\/p>\n
Creating an own Angular Package that can be used with Closure<\/h2>\n
Creating an own Angular Package that can be used together with the closure compiler is quite easy. You just need to align with the conventions for the Angular Package Format<\/a>. The most important thing to consider for Closure is providing a build using the FESM15 format. This means that you have to use EcmaScript 2015+ with EcmaScript Modules. Furthermore, you also have to \"flatten\" everything into one file which is used as the package's entry file. The Angular Package Format also tells us to provide your code in other formats, but here I'm just focusing on FESM15.<\/p>\n
For testing purposes, I've created such a package with some demo code. It's called angular-stuff-lib<\/a> and just contains a simple Angular Module with some a DemoComponent<\/code>.<\/p>\n
@NgModule({\n    imports: [\n        CommonModule,\n        FormsModule,\n        HttpModule\n    ],\n    declarations: [\n        DemoComponent\n    ],\n    exports: [\n        DemoComponent\n    ]\n})\nexport class LibStarterModule {\n\n    static forRoot(): ModuleWithProviders {\n        return {\n            ngModule: LibStarterModule,\n            providers: [\n                DemoService\n            ]\n        };\n    }\n\n}\n<\/code><\/pre>\n
Its forRoot<\/code> method returns this module with a DemoService<\/code>. Using this method you can make sure that the service is only registered with your application's RootModule<\/code> and not with other modules that import this one.<\/p>\n
The package uses the following tsconfig.json<\/code>:<\/p>\n
{\n  \"compilerOptions\": {\n    \"module\": \"es2015\",\n    \"target\": \"es2015\",\n    \"outDir\": \"build\",\n    \"noImplicitAny\": true,\n    \"emitDecoratorMetadata\": true,\n    \"experimentalDecorators\": true,\n    \"declaration\": true,\n    \"moduleResolution\": \"node\",\n    \"noUnusedLocals\": true,\n    \"types\": [\n      \"hammerjs\",\n      \"jasmine\",\n      \"node\"\n    ],\n    \"lib\": [\"es2015\", \"dom\"]\n  },\n  \"files\": [\n    \"index.ts\"\n  ],\n  \"angularCompilerOptions\": {\n    \"strictMetadataEmit\": true,\n    \"skipTemplateCodegen\": true,\n    \"annotationsAs\": \"static fields\",\n    \"annotateForClosureCompiler\": true,\n    \"flatModuleOutFile\": \"stuff-lib.js\",\n    \"flatModuleId\": \"stuff-lib\"\n  }\n}\n<\/code><\/pre>\n
Please note several things here:<\/p>\n