feat(ssr-perf-check): check whether server side rendering is used

[asollberger]

• performance gain by not bundling for the server when ssr is not in use

[Aukevanoost]

I like the idea but this seems more like a half-fix.

The packages are only being compiled if the platform is "node". Therefore, hypothetically it shouldnt compile dependencies if they're not marked as "node" in the first place.

An ideal solution would be to switch to a general "node" or "browser" platform in the federation.config.js to choose if all packages should be compiled as node or browser.

Let me know what you think.

[asollberger]

I'm not sure I fully understand your comment. The way I understand the four builds is that, when you run a simple frontend build, you only need to compile the browser part, when you're running both frontend and backend (server side rendering), you need to run the browser and the node build. I have not used the SSR build at all yet, so I'm not as familiar witth it.
Can you elaborate on what you're suggesting?

[Aukevanoost]

Thank you for your comment,

In the build angular process, the splitShared function creates 4 groups of dependencies based on if they're marked as platform: "node" or not, which can be marked per external in the federation.config.js.

My first point

Since in a non-ssr setup such as yours, the "sharedServer" object is empty , (because there are no node packages, you can check the splitShared function), the bundleShared function is not performing any actions. However, I saw the function doing other things as well. Therefore, wouldn't it make more sense to have a check if there are any "node" externals, so if the object is not empty? Instead of an extra ssr flag.

My second point

I am not entirely sure why, but apparently some packages can be node and some can be browser. I am doubting that this is desired in an application. Therefore the suggestion, shouldn't we remove the node check entirely and go for your solution of a global "is ssr" instead of "platform: node" per external.

Edit: maybe this is intended indeed, so we can skip the second discussion point.