For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

Thanks

This need to be solved differently. Sorting by module I'd basically puts modules in a kind of random order when deterministic module IDs is used. This hurts gzip compression quite a lot compared to ordered by identifier. By identifier puts modules with a similar path next to each other and that compresses much better.
I made a similar change a few years ago and it needed to be reverted...

This need to be solved differently. Sorting by module I'd basically puts modules in a kind of random order when deterministic module IDs is used. This hurts gzip compression quite a lot compared to ordered by identifier. By identifier puts modules with a similar path next to each other and that compresses much better. I made a similar change a few years ago and it needed to be reverted...

I'd expect the order to only meaningfully affect compressibility in unminified builds, though? The paths shouldn't appear in code in a minified build, so I don't see how sorting by identifier would help.

The alternative we considered was to update the sort by identifier function to perform the same portabilization that the DeterministicModuleIdsPlugin does on the identifiers before comparing, but that's likely to hurt performance quite a bit, since even with a cache, it's a lot of lookups to add to the comparison.

Compression is affected by the order as it depends on which modules are placed next to each other in the chunk. Gzip only has a certain context window to copy similar sequences and copying from nearby code is cheaper. Imagine you have a folder with 100 icon components that all lock exactly the same except for the icon path. Sorting by identifier places them all next to each other, which sorting by module id does not.

@dmichon-msft @sokra What is our final solution, because the problem of non-deterministic builds on different OS also brings problems, previously, I received feedback quite often to pay attention to this issue.

It seems that the issue is caused by file path across different OS.

So can we

1. Simply normalize the module identifier by replace(/\\/g, '/') then perform the actual sorting
2. Use Intl.Collator.prototype.compare(),

And I tested it locally using the repo mentioned in the issue above. Sorting by module identifier compress better (71.0% vs. 69.4%), resulting in a ~2 KB smaller compressed size.

➜  gzip -l ./dist-identifiers/jszip-bundle-repro.js.gz 
  compressed uncompressed  ratio uncompressed_name
       35306       122129  71.0% ./dist-identifiers/jszip-bundle-repro.js
➜  gzip -l ./dist-moduleIds/jszip-bundle-repro.js.gz  
  compressed uncompressed  ratio uncompressed_name
       37305       122129  69.4% ./dist-moduleIds/jszip-bundle-repro.js

It's not just the / vs \\ in path separators; identifier is also an absolute path and therefore external modules (which have identifiers like "external react" will sort differently on Windows against actual modules depending on which drive the file is on.

@dmichon-msft

Could you provide additional examples or detailed clarify? I’m sorry, but I’m not fully understanding your idea.

c:/git/project/some-file.js
external react
g:/git/project/some-file.js

The identifier for external react sorts differently depending on the path to the folder where the project is checked out to on Windows.

Granted, the technically correct names would be C:/git/project/some-file.js and G:/git/project/some-file.js, but it is valid to have the lowercase letter.

Most likely the correct long-term solution here is that we should use for sorting the result of getFullModuleName(module, compiler.context, compiler.root) instead of module.identifier() or the assigned id.

Most likely the correct long-term solution here is that we should use for sorting the result of getFullModuleName(module, compiler.context, compiler.root) instead of module.identifier() or the assigned id.