Update/Fix 24/2/2022
It appears that in the end much of this issue was down to a basic error on my part! I have previously documented here and here about the collision of object namespaces when loading multiple webpack bundles for separately deployed web components/angular elements. My solution is to perform a custom post build step to rename the root webpack objects to be unique for each webpack deployment.
This requires building to be done using npm via npm run build rather than the basic angular/cli ng build. Unfortunately I did the latter when initially rebuilding the microapps, hence the post build step did not run and I suffered the consequences I have seen previously due to namespace collisions. Once I rebuild everything correctly, all the microapps worked fine.
Original Post
I had reinstalled a PC from scratch with Windows 10, and this required rebuilding my whole dev environment from scratch. I hit some issues when I just simplistically tried the latest node via nvm install, and the latest angular (14) on projects previously run under angular 11 – builds failed and would not complete. Initially I had failed to install node-sass, so installing this helped, but I was still getting webpack errors on building.
I reverted to angular 11, but also reverted node as well. Finding a compatibility matrix for the versions was tricky but this one on stack overflow was a real help. I therefore reverted node to 12.11.1 using nvm install 12.11.1., and reverted node-sass to 5.0 due to some build errors that stated that 4.0 or 5.0 was needed.
Having done this, I was able to do a build using ng build, but this would not run using http-server, which gave the error “Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client”. My next action was to suspend/pause Kaspersky Antivirus, which helped, as it revealed a firewall port that I needed to enable. When I then immediately tried running directly using ng serve, this worked fine and I was finally able to successfully run my microapp fabric.
I then uploaded the built microapp as a test version under my zen hosting and tried running it from there. This ran fine with no errors, pointing to a local issue with my http-server. This likely needed an older version. I reverted to 0.12.2 to correspond with the current version when I last worked on the microapps, using the http-server version list here, but this did not work.
I then checked exactly which versions of key components had been used successfully under Windows 7, and reverted to exactly those versions. These were v15.5.0 of node.js, and v0.12.3 of http-server. This worked successfully, and I was able to run compiled versions of both the fabric and the dataview microapp. Whilst I could have checked the versions used previously more carefully, this certainly highlights the potential brittleness of the environment as a whole to version changes.
I then upgraded http-server to the latest version and tried again, and everything still worked fine. Therefore, this definitely appears to point to an issue with the version of node.js alone. It also highlights issues with the version matrix I hunted down previously as above. I ended up using a later version of node which was technically incompatible in terms of the above version matrix, but which worked successfully, whereas a version mandated by the version matrix failed completely with the above error.
This whole area of versioning can certainly prove to be an unexpected and ill-documented minefield!