Current implementation of forcing us to report the progress fraction has a lot of limitations:

1. Hides the done and total values data from callbacks. This data might be useful in various implementations.
2. Takes away the ability to handle progress of jobs that don't know about the total value. Some operations just don't know the totalSize, but could still report the progress of how much data has been processed thus far.
3. Inaccurate progress reporting in PProgress.all(). Without p-progress, or callback consumers knowing the totals, each job is equal no matter how much data it is processing.

I propose not enforcing the passing of fraction, but instead keeping track of both done and total values, reporting them, and letting the user decide how to handle it. This will give us more options and data in our progress implementations.

API:

// current
progress(done / total);
// proposal
progress(done, [total]);

The onProgress callback would than report these values in 1st and 2nd argument. If total is undefined, the end is unknown and user can switch handling:

progressPromise.onProgress((done, total) => {
  if (total === undefined) {
    console.log(`${done} bytes processed thus far`);
  } else {
    console.log(`${(done / total) * 100}% done`);
  }
});

In PProgress.all().onProgress callback, the done and total values in onProgress callback will be the total additions of both of the values of all passes progress promisses. And if any of the promisses is missing the total value, the resulting onProgress callback will also receive undefined as total, since we can no longer tell what the total of all promisses is now.

Huge benefit of knowing about the total total in PProgress.all() callback is a more accurate calculation of the whole progress. For example, if you have 2 jobs, one is processing 1KB, another is processing 99KB, and the 1st ends while the 2nd hasn't even started, you now have an accurate progress of 0.01, instead of 0.5. And if you do want it to report that 0.5, well you just do this in each job progress report:

progress(done / total, 1);

And now each job is equal no matter of the amount of data it's processing.

As you see, this kind of API would give us a lot more power, options, data, and ability to handle jobs with unknown totals in our implementations, while still remaining very simple.