Hi:
I want to publish ionic 4 project but I want it all to be combined to one file & minifed & uglified (=Obfuscate).
In v3/2 it was dead easy: just add parameters (–uglifyjs, --minifyjs) in the command line (cli) of the build/publish command and you were set to go.
Now it does not exists.
Also, I can’t seem to do it in npm/gulp/grunt because of the amount of files that exists and do it with .
How do it?
Is there a step by step tutorial for this?
Build the application with --prod and with --release
Hi:
Thanks for answering but I that that and huge amount of javascript files was in the apk.
What is up with v4? How to combine it all?
Hi
that is because likely all components/pages are lazy loaded, meaning they are chopped in tiny js chunks, to support fast loading.
While I don’t know if it will make one big JS bundle, removing lazy loading does reduce the file number.
I never care/nor want to meddle with the result in the www folder - with assets published in the apk - after a prod build (or have any requirements for its content) - that is just the angular/webpack/gradle magic I rely on
But I do wonder what is the use case to desire a single js file. Can you explain the use case why you care about the number of files in the www assets in the APK file?
Hi:
So, How to disable lazy loading?
It will good to have a single file for uglification & for people won’t reverse engineer the code, more easy to control one file during deployment to web, less calls to server on web app (not for device app).
Hi
Lazy loading is not a switch, but the way you have setup the routing (in Angular). So a code pattern. Lazy loading is dscribed here: https://angular.io/guide/lazy-loading-ngmodules, so you need to do the opposite which is described I don’t know where.
Your arguments for not lazy loading actually are my arguments to go for lazy loading. The lazy loading allows me to have an app that loads fast so the user can interact asap, meanwhile the rest is loaded in memory. The files are locally served, not on a webserver, so there is no performance degradation because of internal web calls (talking about an APK!). In fact, if you make it one bundle, the time until first meaningful paint, ability to interact will be highest.
Published on the web, like PWA, or just plain hosting, lazy loading is even more important, as the loading of one chunk will be even a bigger nightmare compared to many chunks, as I said, all chunks are/can be loaded on the background (depending the configuration). Here you can choose to make the web app a PWA, with aggressive prefetch, so the performance is even better compared to non PWA lazy loaded stuff.
As to reverse engineering, splitting in various chunks with awfull names to me seems to give more hurdles to reverse engineer then to make one JS.
If your app is really that important, then someone will manage to reverse engineer it irrespective of your efforts to hide. But in general, for the most apps, reverse engineering code is less attractive then building from scratch stealing the UI flow and google to search for libraries to build the code. If you bake secret API keys and secrets in your app, they also will be found, irrespective what you do. That is general bad practice in any code in any language that gets stored on the local device.
As to web deployment ease, I don’t see the point either unless you use some UI based FTP solution to upload and you have to select each individual file. Nowadays, with CLI uploads (like firebase deploy), the asset count does not matter.
Anyway, happy to hear the contrary, given your experiences…
Hi:
10x for your detailed response.
I will try the link you mentioned and see how it will go.