avoidwork / filesize.js

JavaScript library to generate a human readable String describing the file size
https://filesizejs.com
BSD 3-Clause "New" or "Revised" License
1.61k stars 97 forks source link

1125899906842620 bytes gives the result of 1024 TB because of rounding #103

Closed ulitiy closed 5 years ago

ulitiy commented 5 years ago

I see the only way of solving it – very inelegant corner case management.

        let res = parseFloat((bytes / (1024 ** pow)).toFixed(precision));
        if (res === 1024) {
            res = 1;
            pow++;
        }
avoidwork commented 5 years ago

Thanks for reporting this

zypA13510 commented 5 years ago

For those who are trying to make sense of this change:

1PB != 1125899906842620 bytes, 1PB == 1125899906842624 bytes, yes. But filesize is expected to round up the result, e.g. filesize(1048574) == '1 MB' although 1024*1024 == 1048576

Hope this helps those who look for changelog like me.

avoidwork commented 5 years ago

I hope you would understand the issue and the fix based on the details provided, and the single commit to address the issue. A changelog won't help you reason why something is modified, it's just a subset of the commit log.

avoidwork commented 5 years ago

https://en.wikipedia.org/wiki/Changelog <--- seriously stop being so entitled with the notion of the changelog already, and either land it or stfu.

https://devhints.io/git-log <-- this is required reading

zypA13510 commented 5 years ago

Without a changelog, the only way to determine if an upgrade is "safe" or not is to look at the commit log, which I was doing. And clearly I failed to understand this change at first look.

I'm not arguing with you whether providing a changelog is a good thing or not, I'm merely giving people (who look for the details of an update, people like me) a better understanding of this issue and that's it, what's so wrong about that? This is what I saw, and how I came to this issue, and it only makes me confused because 1125899906842620 is clearly not equal to 1PB. Your test case is even more confusing (to me at least). So that's why I decided to leave a note to future readers.

Btw, providing a changelog is not that difficult, you may want to look into conventional commits and semantic release

jennifer-shehane commented 4 years ago

Reading through every commit for every package that is a dependency of a project is not sustainable. I would argue that a changelog is a very good thing. I too came looking for changes and am reading entire threads of the project to see what changed, which is not ideal. @zypA13510 Thanks for your comment - it makes the issue and commit much clearer.

avoidwork commented 4 years ago

Maintaining a change log is a job of a technical writer. I am not a technical writer. Anyone that feels that one should exist is welcome to spend their time curating the git history to create whatever is deemed ideal.