Closed mojoaxel closed 1 year ago
Can you better explain the use case for this?
Turning it on won't break the plugin, but it does add a bit more delay in the build process, and I'm struggling to understand the situations where this information would be useful.
This plugin is designed for compiling a web app into a single (and uncompressed) HTML file, so you can open and run it from a file system directly.
Using this plugin to build a site that is served via a web server would normally be a bad idea, since it subverts all of the performance benefits that come from modern web servers and bundlers: parallel connections, partial caching, on-demand asset loading, not having to base64-encode binary assets, not having to block compilation and rendering until the whole page loads, etc.
I can imagine using it for some limited-capability embedded system web servers, like ESP8266WebServer, but those don't tend to support on-the-fly compression anyway.
I'm happy to explain!
As you expected, I'm deploying to a very limited embedded device. While one-the-fly compression is not supported, it looks like the embedded webserver can deliver pre-compressed assets. Because the flash memory is very limited I need to keep an eye on the the bundle size.
As I see it, the option reportCompressedSize
does absolutely no harm to vite-plugin-singlefile. Users that don't want or need the gzip target size being reported can just disable the setting. Users like me that are interested in this information should be able to use it!
@richardtallent If you think it is necessary I can add a note to the README and advice users to disable reportCompressedSize
which is on by default!?
Thanks, makes sense now, fixed in 0.13.5!
It would be nice to also show gzip for the resulting
index.html
file.For this to work first https://github.com/vitejs/vite/pull/12485 needs to get merged.
Than we also need to allow
reportCompressedSize
to be true which is disabled at the moment.I'll provide a PR for this!