New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Size is reported as 0 bytes since upgrading to 6.x #261
Comments
It could be related to webpack 4→5 changes in 6.0.
|
The |
Change |
I added a test for It is DX issue, but since we found a fix and can’t easily reproduce it in test environment, I am closing the bug. Bug I will be happy if you will reproduce the bug in test environment so we will be able to fix it in |
Unfortunately this doesn't fix the issue for me. I get the same result running locally:
And the same 0 byte result happens under GHA: https://github.com/snout-router/regexp/runs/3893923974?check_suite_focus=true#step:4:36 |
Sorry. I'll try to see if I can put together a simpler repro case. |
Oops. I forget to remove another trick. It help me adding |
I am working on a better solution |
I get results by adding this 👍 Although if it's possible it'd be great to have an option that was equivalent to |
@ludofischer webpack 5 started to remove any exports from bundles if we do not pass Any idea how to disable it for non- |
You might also be interested to know that the P.S. I'm also getting some pretty surprising results for the size of the CJS version, but I'll make another issue for that if necessary. |
@ludofischer I added |
In my case all .cjs files' sizes were increased approximately by 140-150 bytes. Is there any way to preserve temporary bundles' files, in order to check manually, by looking through them with my own eyes, whats going on? |
@yumauri we already subtract wrapper size from the bundle size. In my case, I got 20-30 extra bytes, but because of the opposite reason. webpack 5 wrapper is very small and gzip now can use it to reduce size of your JS code. So for my case the result become bigger, but a little more fair. |
Sorry, I don't know about this. I would need to look into the webpack docs :-) Apparently you can use https://webpack.js.org/configuration/optimization/#optimizationusedexports but it looks like it's going to disable tree shaking even for transitive dependencies, so it will report a larger bundle size than what will happen in production. With tree-shaking the question 'how much does this add to the bundle' has more than one answer. It might really be zero if the user just imports your library without calling it…
When we calculate the bundle size, we subtract the 'empty' bundle size to get the final bundle size. With webpack 4 even bundling empty code would create some wrappers. I think what might be happening is that with webpack 5 the empty bundle size is almost 0, so adding any code makes a larger difference. |
To be clear, what I expected by leaving off
My guess is that most developers would want to know how much "extra" bundle size they'd be getting by adding the library to an existing project that already uses Webpack, and hence they've already decided that they're comfortable with the overhead of Webpack itself. It's much less useful to know how big a library would be if you bundled only that singular library and nothing else. |
@ludofischer we can add some optional like import * as all from '../entry.js'
console.log(all) |
For my own libraries, I would prefer to use the |
The problem of this way is that we will not substract this entry point from the library size. It is OK for 1-10K projects, but not so good for projects like from issue owner. |
What about outputting best/worst case numbers by default (so both the current configuration and using the |
Hm. I like the idea. |
Which limit would make CI fail though? Should the |
My idea is to use But we need to be sure that we can use |
I'm trying to upgrade
size-limit
to6.0.3
in my projects. I'm also using@size-limit/preset-small-lib
at the same version. I haven't made any changes to my config or code, but I'm now seeing sizes of 0 bytes:Versus the output I get from
size-limit@^5.0.3
:This results in reports indicating that I've removed 100% of my code:
The text was updated successfully, but these errors were encountered: