Thanks for the PR! I'm not 100% sure about the current approach though 🤔

First of all, this tries to import crypto even in browser environments leading to the following error, as can be seen on the CI:

Module not found: Error: Can't resolve 'crypto' in '/home/runner/work/uuid/uuid/dist/esm-browser'

But even without that, since it takes the UUID string returned from randomUUID and turns it back into bytes I'm not sure that there is any benefit over just using the default rng which will be crypto.randomFillSync (with a pool) on Node.js? 🤔

How about falling back to randomUUID only when we don't need the bytes?

function v4(options, buf, offset) {
  options = options || {};

  if (buf == null && options.random == null && options.rng == null) {
    return randomUUID()
  }

  // ...
}

We would also need to solve the importing of crypto which I think we would do by creating two files, e.g. native.js & native-browser.js.

native.js would export randomUUID on Node.js platforms where it's available.

native-browser.js would export randomUUID once randomUUID is added to browsers.

This would then be configured the same way as e.g. sha1 and rng are package.json -> "browser".

I don't like current aproach too much too, I was thinking more about uuid working as a polyfill, but the buffer filling thing or the options made it more complex. I like your idea of using it as an optimization corner case. By the way, native randomUUID() already manages a data pool itself for up to 128 UUIDs by default.

Where are we at with this?

Implemented the changes I described in a new PR: #600

It gives an 11x speedup on my computer 🤩