Salient Soft

I needed to upgrade node/angular/PrimeNG/primeNG Showcase to the latest versions (Node 15.5, Angular 11, PrimeNG 11) , but I also wanted to be able to maintain projects on older versions using Angular 6.

This post details how to do this with nvm under Linux, but an alternive nvm implementation is needed for windows. This is detailed here, and the git repo for this version with full instructions is here . I uninstalled the existing angular cli/PrimeNG via npm uninstall, and then removed my node installation via control panel.

Next I installed nvm per the above post for the windows implementation. Per the above post for the Linux version, I used nvm install to install node versions 10.4.0 and 15.5. I then selected each in turn via nvm use, and for each version, I installed the desired angular/cli for that version globally in the standard way, using for example npm install -g @angular/cli@6.2.2 for the legacy version. Note that using -g in this case installs globally for the currently selected node version only, so when you switch/select the current node version with npm use, you also automatically select the angular/cli version that you previously installed with it.

Having done this, and as per the above posts, you must remember to select the desired node version with nvm use in each command window or batch file that you use. The version is not selected for a project directory, but is per command window/process.

I was then able to use both the latest angular/primeNG and the legacy ones, and could build and run with both on the same machine.

One issue I hit with primeNG when performing npm install on the latest version was a bug in the latest version of node: “Cannot destructure property ‘name’ of ‘node’ as it is null.” This bug is detailed here. Per the post comment by Mika Bertels, I reverted to npm 6 using npm i -g npm@6. In my case, npm gave a file already exists error, so as hinted by node I used the –force flag to force the reversion of version. This worked fine, and my npm install of primeng worked successfully

Per the instructions here, the primeng 11 can just be installed and then run with ng serve, and I did not hit any issues with theme building etc. which I did with earlier versions, presumably due to all the themeing changes. Note also that this setup guide for primeng explains how to install primeng and primeicons when using with your own project – I did not need to do this initially as I was just running the showcase.

Comments Off on Installing/running multiple Node/Angular/primeng + showcase versions under windows

I did an npm-update of  my microapp-fabric-prototype and my microapp-dataview app.

This resulted in the upgrade of

"@angular-devkit/build-angular": "~0.8.2"

to:

"@angular-devkit/build-angular": "^0.13.4",

in package.json. This caused my microapp POC to fail.

When the host Microapp Fabric application receives a menu action from a menu item click, it dynamically creates an angular element in its microapp container; the element contains the target microapp.

This should result in the initialisation of the angular runtime environment for the custom angular element, including initialisation of the IOC/DI environment for the target angular element app. This includes creation of all the required components/services and calling of their various constructors.

Unfortunately, with the later version above, instead of initialising the app-config-service in the angular element, it tried to re-initialise the app-config-service for the host app a second time which caused the whole app to fail.

The precise reason for the issue is not known. Both apps have some services (such as app-config-service) which have the same name, and sometimes when debugging it can cause confusion when trying to navigate the source maps in the debugger.

However, as all the services and components for each app (the main app and any angular-elements) are correctly encapsulated, there is never a confusion between them, even though the script environment is common and not shadowed. (In this demo, we are using a shadow dom for the W3C custom elements/angular elements, but the javascript is not shadowed. This is correct, and allows angular to have a runtime environment which persists across the main app and all the angular elements, and manages them all correctly).

As I have found before, care needs to be taken when upgrading versions – this is quite often not straightforward and needs care to check out dependencies that cause failures. Care will be needed I suspect when upgrading from Angular 6.1.7 to Angular 7!

No Comments »