Skip to content
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

Display difference from the previous build in filesize #326

Closed
gaearon opened this issue Aug 2, 2016 · 13 comments · Fixed by #340
Closed

Display difference from the previous build in filesize #326

gaearon opened this issue Aug 2, 2016 · 13 comments · Fixed by #340

Comments

@gaearon
Copy link
Contributor

gaearon commented Aug 2, 2016

Update: The issue is claimed by @elijahmanor.

Seems like a nice thing to do.
We can read the files before clearing the build folder.

It could look like this:

Creating an optimized production build...
Compiled successfully.

File sizes after gzip:

  48.73 KB (+2.12 KB)  build/static/js/main.42e82b08.js
  289 B                build/static/css/main.9a0fe4f1.css

(Right now we display the build size but not the delta.)

@gaearon
Copy link
Contributor Author

gaearon commented Aug 2, 2016

If you intend to work on this please comment here so multiple people don’t grab this at the same time.

Relevant code in the build script.

Here’s where we clean the folder so you’ll want to read sizes before that.

Read how to contribute.

@elijahmanor
Copy link
Contributor

I can work on that tonight

@gaearon gaearon changed the title Display delta from the previous build in filesize Display difference from the previous build in filesize Aug 2, 2016
@gaearon
Copy link
Contributor Author

gaearon commented Aug 2, 2016

Great! Let me know if you have any troubles, happy to walk you through the code.

kripod added a commit to kripod/create-react-app that referenced this issue Aug 2, 2016
@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

Sorry for stepping in, I felt like I was able to take this task, too... 😄

@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

I'm wondering how the hash of the old file could be retrieved...

@gaearon
Copy link
Contributor Author

gaearon commented Aug 2, 2016

@kripod

Hi, thanks but I think this is not a very nice way to contribute.
I believe I posted above:

Update:
The issue is claimed by @elijahmanor.

I also wrote:

If you intend to work on this please comment here so multiple people don’t grab this at the same time.

Then @elijahmanor commented that he plans to work on this, and I wrote:

Great! Let me know if you have any troubles, happy to walk you through the code.

I appreciate the intention to contribute but this just won’t work well if everyone keeps grabbing issues claimed by somebody else.

There are other issues, like #73, that need somebody to work on them. I’d appreciate if you could look at that issue instead.

If @elijahmanor later decides he’d rather not work on this, I’d be happy to reassign this to you.
Thank you!

@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

I'm sorry to interrupt, and will wait on the answer of @elijahmanor. Anyway, old build hashes could be retrieved from a generated manifest file or deterministically. Which method should be preferred?

@gaearon
Copy link
Contributor Author

gaearon commented Aug 2, 2016

I should’ve made a larger heading for this in the original post (I’ll fix that now).
Maybe should introduce a GitHub label for claimed issues.

@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

That sounds great, I apologize I didn't notice that before trying to contribute...

Anyway, old build hashes could be retrieved from a generated manifest file or deterministically. Which method should be preferred?

@gaearon
Copy link
Contributor Author

gaearon commented Aug 2, 2016

No problem, it’s my fault, I should make the guidelines clearer.


As for your question, is there a particular reason webpack for this at all? I’d probably do the easy thing and just read sizes of all css/js files deeply inside build directory before removing it.

@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

That sounds like a plan, although that way, it'd read some old files from the disk unnecessarily. I prefer comparing only the newly-written files with their old counterparts. A regex could be used to remove hash strings before comparing file names.

@kripod
Copy link
Contributor

kripod commented Aug 2, 2016

On a second thought, you're right: reading old files with unknown hashes deterministically is a painful task. Premature optimization is the root of evil. 😊

@elijahmanor
Copy link
Contributor

yes, that is the route that I took tonight... recursively found files in build folder and removed the hashes to build an object map of previous sizes that can be used later on to compare delta sizes.

@lock lock bot locked and limited conversation to collaborators Jan 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants