@arcgis/core Angular Nx Build becomes incredibly big

169
2
Jump to solution
03-16-2021 05:54 AM
RichardReinicke
Occasional Contributor

Hello,

I'm currently building a prototype app with the new @Anonymous User/core (4.18.1) package and Nx Angular monorepos (Angular 11).

If I build the application I get a number of compiler messages.

Warning: E:\Projekte\nx-hwrm\nx-hwrm\libs\shared\feature-mapping-esri\node_modul
es\@arcgis\core\intl\moment.js depends on 'moment/locale/ko.js'. CommonJS or AMD
dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependenc
ies

Warning: E:\Projekte\nx-hwrm\nx-hwrm\libs\shared\feature-mapping-esri\node_modul
es\@arcgis\core\intl\moment.js depends on 'moment/locale/ja.js'. CommonJS or AMD
dependencies can cause optimization bailouts.
For more info see: https://angular.io/guide/build#configuring-commonjs-dependenc
ies

and

Warning: ./libs/shared/feature-mapping-esri/node_modules/@arcgis/core/core/worke
rs/workers.js 5:863-872
Critical dependency: the request of a dependency is an expression

Warning: ./libs/shared/feature-mapping-esri/node_modules/@arcgis/core/core/worke
rs/WorkerFallback.js 5:2264-2273
Critical dependency: the request of a dependency is an expression

also the build generates more than 170 numbered bundles together 8MB. If I also include the whole esri assets folder this is another ~22MB.

I followed this guide:
https://developers.arcgis.com/javascript/latest/es-modules/

Esri assets are copied to output dist folder with angular.json:

"assets": {
    {
        "glob": "**/*",
        "input": "libs/shared/feature-mapping-esri/node_modules/@arcgis/core/assets",
        "output": "assets/"
    }
}

Is there a way to have a more compact Angular build?

0 Kudos
1 Solution

Accepted Solutions
AndyGup
Esri Regular Contributor

Lots of questions here. For the on-disk bundle size, what you see in a production build output is about as small as that footprint will get. The API will only use what's need at application runtime. If you have on-disk size limitations because you are running something like a SalesForce lightning component then there are some other approaches you might consider.

With regards to the assets, try testing with the latest "next" build: npm i @Anonymous User/core@next (ignore the weird casing, it's caused by the text editor, the npm command is all lower case). When we release at 4.19 (early April) the assets are pulled from a CDN by default, so that will immediately result in an on-disk production build size decrease. You can override this if you want, in order to use the local assets.

4.19 also removes the critical dependency warnings. 

You can remove the "moment" warnings by adding the following to angular.json > build > options: 

            "allowedCommonJsDependencies": [
              "moment"
            ],    

 

View solution in original post

0 Kudos
2 Replies
AndyGup
Esri Regular Contributor

Lots of questions here. For the on-disk bundle size, what you see in a production build output is about as small as that footprint will get. The API will only use what's need at application runtime. If you have on-disk size limitations because you are running something like a SalesForce lightning component then there are some other approaches you might consider.

With regards to the assets, try testing with the latest "next" build: npm i @Anonymous User/core@next (ignore the weird casing, it's caused by the text editor, the npm command is all lower case). When we release at 4.19 (early April) the assets are pulled from a CDN by default, so that will immediately result in an on-disk production build size decrease. You can override this if you want, in order to use the local assets.

4.19 also removes the critical dependency warnings. 

You can remove the "moment" warnings by adding the following to angular.json > build > options: 

            "allowedCommonJsDependencies": [
              "moment"
            ],    

 

View solution in original post

0 Kudos
RichardReinicke
Occasional Contributor

Hello @AndyGup,

thank you very much for taking time to answer all my questions.

The bundle size is not a general problem but at the moment it slows down our Azure build. This is something we can enhance on our own with Azure and Nx tools.

For now I set the the version to @next and I will keep my eyes open for the new release. The unwanted build messages disappeared.

0 Kudos