Salient Soft

An old chestnut this – when upgrading from an old version on my hosted environment, my chrome based dev desktop worked fine, mainly due to my habit of hitting ctrl/f5 which clears the cache before loading.

However, on my android mobile, this needs an explicit cache clear before loading the page e.g. via the settings/history etc., which I was not in the habit of doing. Therefore when testing the new version on mobile, it failed. The new version was a production build which did not have source maps. The old version was a dev one with source maps. The console errors indicated an inability to find and load the source maps, which were not present in the latest prod deployment, but were still being requested by the cached scripts on the mobile. An explicit cache clear solved the problem. 

When I tried this again on the desktop without the cache clear, i.e. with a straight refresh, I was able to duplicate the error seen on the android chrome.

Note that the problem only applies to the fabric deployment as all the others have a timestamp (ts=) querystring parameter added to the scripts when loading, which prevents caching. I normally disable the output hashing on all microapps including the fabric for convenience, to avoid editing the app config to change the names of all the dynamically loaded scripts, even for a prod build.

Doing this on the Fabric is unnecessary as the scripts are not loaded dynamically by my code, so if I left the hashing on for the fabric, this would solve the problem, as the timestamp querystring would sort the issue for all the others.

Going forward, I intend to improve automation of the build process for hosted deployments by providing e.g. an NPM script to build all the microapps into a single zipped deployment which can be just uploaded and unzipped – at present I am having to do each one individually and copy up the dist directory. Whilst all this is only a POC application, I am doing it often enough to make this worthwhile so as not to waste time or make mistakes with it.

Doing this would also allow the possibility of using my own timestamps on all the filenames for every script, and dynamically modifying the config to incorporate the timestamps in the build script. This would allow caching to be left enabled for the code scripts (but not for the config), which would actually be a benefit as it would improve startup times and lessen bandwidth usage – especially relevant for mobiles. I could add a fabric config parameter to indicate whether the querystring timestamps should be added or not when loading scripts, so that the feature can still be used when needed. Perhaps I could leave this enabled for dev mode and not bother with timestamps on the actual filenames for example.

Using my own timestamps on the names would simplify and standardise the names, as I could use an identical timestamp on all scripts for every microapp done as part of a given build, to simplify naming and build automation – I would only need to pass around one single timestamp parameter which would be used for all generated script files and in the config.

Comments Off on Caching of old microapp scripts breaks new version

This follows on from my original post here for Angular 6.

In Angular 11, the up-and-coming approach to this is to use Module Federation for remote loading of microapps/micro-frontends. Manfred Steyer has a new article series on this whole approach here, and the second article about using Angular for this may be found here.

My issue with module federation at present is that it is still appears too nascent to simply ‘just work as standard’ with angular – the above posts need a number of workarounds including the use of yarn, and I was unwilling to switch to this method just for my present requirement which is just the generation of simple proof of concept work.

At present, I am therefore continuing to use my original approach as above for my POC work, as it still works with Angular 11. I have tweaked the approach a little to allow performing production builds, by disabling the hashes added to the filenames (I already use my own alternative method for cache busting/cache avoidance using a query string parameter). Details are shown below.

package.json scripts section

{
  "name": "microapp-fabric-prototype",
  "version": "0.0.0",
  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "prebuild": "npm run scss",
    "build": "ng build",
    "postbuild": "node post-build.js",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e",
    "scss": "npm run scss1",
    "scss1": "cd src/assets/resources/themes/salient-v11-violet && sass theme.scss:theme.css --source-map .",
    "prebuildProd": "npm run scss",
    "buildProd": "ng build --prod --output-hashing none",
    "postbuildProd": "node post-build-prod.js"
  },

post-build.js

/* Do post build actions on the webpack bundle.
 * Rename the webpack jsonp objects throughout, to prevent invalid multiple bootstraps due to name collisions
 * This is due to an angular bug - see here: https://github.com/angular/angular/issues/23732
 * This script requires the npm replace package: https://www.npmjs.com/package/replace
 * To install use: "npm install replace -g" */

var replace = require("replace");

doWebpackReplace('MicroappFabric','microapp-fabric-prototype',
 ['main.js', 'polyfills.js', 'runtime.js', 'vendor.js']);

function doWebpackReplace(name, filename, paths) {
 replace({
   regex: '\\["webpackJsonp"\\]',
   replacement: `["webpackJsonp${name}"]`,
   paths: paths.map((p) => `dist\\${filename}\\${p}`),
   recursive: false,
   silent: false,
 });
}

post-build-prod.js

/* Do post production build actions on the webpack bundle.
 * Rename the webpack jsonp objects throughout, to prevent invalid multiple bootstraps due to name collisions
 * This is due to an angular bug - see here: https://github.com/angular/angular/issues/23732
 * This script requires the npm replace package: https://www.npmjs.com/package/replace
 * To install use: "npm install replace -g" */

var replace = require("replace");

doWebpackReplace('MicroappFabric','microapp-fabric-prototype',
 ['main.js', 'polyfills.js', 'runtime.js']);

function doWebpackReplace(name, filename, paths) {
 replace({
   regex: 'window\\.webpackJsonp',
   replacement: `window.webpackJsonp${name}`,
   paths: paths.map((p) => `dist\\${filename}\\${p}`),
   recursive: false,
   silent: false,
 });
}

At present, I will continue to monitor the situation with Module Federation, and will likely switch to using it when it really is working ‘out of the box’ with no tweaks or complications.

Comments Off on Angular 11 – remote loading of Angular Element from separately deployed webpack bundle

When upgrading an angular 4 project (places-admin) to angular 6, I got the above error when building.

The problem and solution are detailed here.

The issue appears to be caused by webpack 4.25.* breaking compatibility with the plugin.

Applying the fix in the above post solved the problem, by adding

“webpack”: “4.24.0”

to the devDependencies section in package.json

Comments Off on Angular build fails with “Progress Plugin Invalid Options”