fix: incorrect usage of Hash.digest

[fkhadra]

Hey,

Hash.digest expect an encoding value as parameter(latin1 | hex | base64).

The absolute path of the file was passed to Hash.digest which is incorrect. To generate a hash
based on the pathname we have to call Hash.update first.

The desired encoding format is then passed to Hash.digest. This remove the need to call toString method.

[codecov-io]

Codecov Report

Merging #347 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #347   +/-   ##
=======================================
  Coverage   69.37%   69.37%           
=======================================
  Files          12       12           
  Lines         382      382           
=======================================
  Hits          265      265           
  Misses        117      117

Impacted Files	Coverage Δ
src/cli.js	62.35% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d0494e7...b19baa8. Read the comment docs.

[styfle]

This looks correct

[styfle]

@guybedford It looks like hashing/caching was added in #162 but does that mean it never working properly?

[guybedford]

So yes, this never worked... Thanks so much for the fix!

Effectively we have always been outputting the ncc run build to /tmpdir/d41d8cd98f00b204e9800998ecf8427e always.

The main important thing is that the directory name is random enough that multiple runs of ncc run can happen in parallel without collision (although even that would only cause issues when deferred asset loads are attempted), but I guess we haven't really hit that specific case for this to be a problem.

We could entirely use a random generator here too, which would probably be even less likely to cause the conflict above.

The other concern over fully random directories, was if the process was interrupted before it can clean up, then we leave behind the temporary folder, so there is a risk of file system bloat which was trying to be avoided by at least having a predictable hash generation based on the name.

Hope that explains somewhat the constraints in play here, and why the issue hasn't been critical.

[fkhadra]

I'm glad it help. Keep up the great work !