Stable names when minifyIdentifiers enabled

[yumauri]

Looks like with option minifyIdentifiers esbuild choose names randomly OR it somehow depends on operating system.

This causes different gzip compression rate for my local machine (macOS) and CI (GitHub action), thus failing build (when using size-limit tool, see this issue).

Is it possible to make short names generation stable over different machines?

[ai]

Random names will also generate different hash on different machines, which could be painful in some environments.

[yumauri]

Unfortunately I tried and failed to create minimal reproduce, even on my files... Maybe there are deeper roots, than I thought.
Maybe @evanw will know better, or at least have a notion, why short names could be different after minification.

[evanw]

They should be stable assuming the inputs to esbuild are the same. Name generation is intended to be completely deterministic.

One think to know is that to improve gzip compression the identifiers are derived from a character frequency analysis of the input source code, so any difference in input source code between two environments can potentially result in different identifiers, even if the overall structure of the resulting code is the same. So that's one thing to check for (e.g. make sure that plugins aren't the problem).

If you can provide a way to reproduce this and it's a bug in esbuild after all, then I can find a way to fix it.

[yumauri]

@evanw Thank you! Issue is exactly this — to test file size with tree-shaking, size-limit generates fake entry point, where imports original file by the full file name. On different environments this path is different, thus causing one small difference in source code.

Not sure if it is bug or no, because when esbuild creates a bundle — there are no any filepathes inside it, so, depending on paths of imported files is a bit strange, what do you think?

[evanw]

I would not consider this a bug with esbuild since esbuild only guarantees that the output will be the same if the input is the same. I can try to adjust the character frequencies to avoid this particular case but the only 100% sure way to guarantee the same output is to have the same input.

Note that even when file paths don't appear in the output directly, the relative paths of input files are still included in hash calculations for output file names. One reason is because different files with the same contents must retain separate module identity for correctness (e.g. #928). Another reason is because source maps contain the relative path to the input file and esbuild currently locks the name of the source map to the name of the output file plus .map at the end (so if the source map contents change, the output file name must change too).

fake entry point, where imports original file by the full file name

By "full file name" do you mean the absolute path to the file? One simple fix could be to use the relative path to the file instead, which would be platform-independent.

[yumauri]

By "full file name" do you mean the absolute path to the file?

Yeah, I mean absolute path :)
I guess your commit should fix this particular case, thank you!

[evanw]

The mitigation was just released in version 0.14.4 so I'm going to close this. Hopefully it works but you should also be able to just use a relative path instead to avoid this.

[yumauri]

Version 0.14.5 has fixed the issue, thank you!