fix: sort all shared items to create deterministic builds when hashes are used

[awesome-q]

When using hashes for the remoteEntry file in the plugin, the hashes are sometimes different because the order of the usedShared object is different. This causes builds to be non-deterministic when in fact nothing has changed. For example:

// vite.config.ts for a host app
defineConfig(() => ({
   // ..rest
   plugins: [
     federation({
       name: "host-app",
       manifest: true,
       filename: "remoteEntry.[hash].js",
       shared: {
          // a bunch of packages,
       }

During 2 builds for the exact same source, the remoteEntry and hostInit may have different hashes because the remoteEntry may differ in the ordering of the usedShared keys:

# build 1 outputs remoteEntry.abcdefg.js:
const usedShared = {
   'some-library-a': { /* config */ },
   'some-library-b': { /* config */ },
}


# build 2 outputs remoteEntry.xyzlmnop.js:
const usedShared = {
   'some-library-b': { /* config */ },
   'some-library-a': { /* config */ }
}

It's a bit hard to reproduce in a toy app since I think the cause is the async hooks across a large number of files in our application, but this simple one-liner ought to fix it.

[gioboa]

Thanks for your help @awesome-q
Have you tried to modify your node_modules to verify this fix? Is it really solving the issue?
If yes, nice catch 👏

[awesome-q]

hey @gioboa - yes I just ran 10 builds on my app with the sorting and without it. With sorting I had identical hashes, and without I had 10 different ones. It's likely some combinations of plugins we have in our build process that cause the timing to vary as rollup does its thing. This change will make the code more resilient as other users are bound to run into similar situations.

[gioboa]

Thanks @awesome-q
Small change, great improvement 👏🎉
Well done 💪