search

mattdesl / budo

:clapper: a dev server for rapid prototyping
MIT License
2.18k stars 106 forks source link

File size in log is way different than what is in the browser #115

Closed quantizor closed 8 years ago

quantizor commented 8 years ago

I can't really share my environment (private source), but I'm seeing something interesting... The file size in the logger is generally at least 2x what the actual bundle size is when received by the browser.

screen shot 2015-12-10 at 5 30 42 pm

screen shot 2015-12-10 at 5 30 56 pm

The script to start budo is:

budo site/index.js:dist/bundle.js -d site -H localhost --colors --live --open --pushstate --iw -- -t babelify -t brfs
mattdesl commented 8 years ago

Thanks for the bug report. I will take a look this week! :smile:

yoshuawuyts commented 8 years ago

@mattdesl not sure what you're currently using, but if it isn't working well this should be fail-proof:

It's a bit dirty, but should work reliably. If that's not a good fit, perhaps size-stream will work.

Hope this is helpful (':

caspervonb commented 8 years ago

Looks like the log is logging the raw size, and its transferred with gzip compression?

quantizor commented 8 years ago

I don't think so. The browser log says it is not.

On Dec 13, 2015, at 12:21 AM, Casper Beyer notifications@github.com wrote:

Looks like the log is logging the raw size, and its transferred with gzip compression?

— Reply to this email directly or view it on GitHub.

mattdesl commented 8 years ago

The current solution in server.js is basically the same as the content-length module. Maybe size-stream will be a better fit, though.

quantizor commented 8 years ago

:tada: Thanks @mattdesl!

mattdesl commented 8 years ago

This should be mostly fixed, let me know if you see further issues.

When the server code is refactored to use filed and other stream-based stuff (see #80), I will try to use size-stream or a similar module, which is likely cleaner than my current approach for getting size.