Should Database<Item> use IndexMap internally?

[ahabhgk]

For now Rspack is using HashMap internally, HashMap is unordered, but in webpack, compilation.chunks is ordered, a real case:

https://github.com/web-infra-dev/rspack/blob/main/packages/rspack/tests/cases/chunks/issue-4338

webpack use MergeDuplicateChunksPlugin to remove the duplicate chunks, webpack will keep 0.js, 2.js, c0.js, c2.js, but Rspack will keep 0.js, 3.js, c1.js, c2.js, this is caused by the different order of iterating compilation.chunks between webpack and Rspack

// for each chunk
for (const chunk of chunks) {

Fortunately, the order of HashMap.keys() is stable, so our output assets are also stable, but once we add more chunks into compilation.chunk_by_ukey, the structure of the HashMap will change, and we will have different output assets for these duplicate chunks, for example:

In above case, if we add another import(), which will create another code-split point, and will add more chunks, the structure of the compilation.chunk_by_ukey will change, and the order will also change, the result of MergeDuplicateChunksPlugin might be:

1.js, 3.js, c1.js, c3.js

and last time it is:

0.js, 3.js, c1.js, c2.js

the result is also correct, but it is bad for caching

Above example is only one case, we may have more potential cases

[bvanjoi]

Fortunately, the order of HashMap.keys() is stable

Why you think HashMap.keys() is stable?

[ahabhgk]

we are using FxHashMap, FxHashMap.keys() is stable