search

ai / size-limit

Calculate the real cost to run your JS app or lib to keep good performance. Show error in pull request if the cost exceeds the limit.
MIT License
6.52k stars 1.82k forks source link

`@size-limit/esbuild` plugin size report stability #274

Closed yumauri closed 2 years ago

yumauri commented 2 years ago

Not sure why, but when I've updated size-limit from 6.0.3 to 7.0.4, and @size-limit/preset-small-lib from 6.0.3 to 7.0.3 (and adjusted file sizes in .size-limit.js) — reported sizes on my local machine (macOS, node 16.13.1) and GitHub action (ubuntu-latest, node 14.18.1 and 16.13.0) are different.

Here is side-by-side comparison, left — GitHub action, right — my local machine: Screenshot 2021-12-12 at 23 40 21

There wasn't such issue with webpack.

ai commented 2 years ago

Short fix: go back to webpack by replacing @size-limit/preset-small-lib to @size-limit/webpack

I am not sure about the full solution, since seems like we have an inconsistency output from esbuild.

Can you report an issue to esbuild?

yumauri commented 2 years ago

I tried docker image node:16.13.0, and it behaves like GitHub action, same sizes reported.

Maybe the issue is not with esbuild, but gzip compression... Because I've tried to check single file with gzip: false option and got same size on macOS and inside docker.

Is there any way to preserve temporary files to compare?

ai commented 2 years ago

Wow, very strange. But why we have the same size with webpack.

Maybe esbuild put functions in a different order?

The simplest way to debug is just console.log in Size Limit sources. You can fork repo, add debug lines and use your fork by replacing npm version to link to GitHub.

yumauri commented 2 years ago

Looks like the issue with minifyIdentifiers option, with it esbuild generates different short names (check mentioned issue I created). I guess possible workaround for a while would be to set minifyIdentifiers: false in the plugin.

ai commented 2 years ago

Thanks for the research. Great work!

I'm afraid that disabling the option will make results too big. Let’s wait a little for esbuild author response.

yumauri commented 2 years ago

I think I got it.

Evan said, that any difference in input source code between two environments can potentially result in different identifiers.

I use import feature of size-limit, to tree-shake only single main function from my source. size-limit then generates fake entry point with import of original file by the absolute path to the file. On different machines this path is different.

I tried to create exactly the same path inside docker container — and voilá! I got same size report results!

ai commented 2 years ago

@yumauri as usual, amazing work!

Can I ask you to send a PR to use relative paths? Sorry, I am too busy this/next week by visiting Russia.

yumauri commented 2 years ago

Evan committed small fix to exclude import files names from frequency analysis, hope it will be enough to fix this particular case.

Besides, I'm not sure how to fix this from the size-limit library side... Because temporary folder (where fake input file is created) could be located by different paths on different machines, so relative paths also would be different...

Should fix create fake input file near the original file? Or copy whole source directory to the temporary folder?

ai commented 2 years ago

Cool. Let’s wait for next esbuild release.

yumauri commented 2 years ago

Version 0.14.5 of esbuild has fixed the case, so I reckon this issue could be closed as well :)