[Proposal] RFC4122 v4 UUIDs

tldr; I would like to revisit, and make a case for, RFC4122 v4 UUIDs. Here’s the start of a proposal: bcoe.github.io/uuid/.

v4 UUIDs are ubiquitous

As Marcos points out in the post “Add UUIDs API to the platform”, uuid is one of the most widely used modules in the JavaScript ecosystem:

uuid is a dependency of over 30,000 modules on npm, and downloaded 40,000,000 times a week (In analyis summarized here, it was found that about 80% of users of the library use the v4 algorithm).

v4 uuid’s have a wide variety of uses, once you start looking for them you see them everywhere:

  • identifiers for request tracing (potentially frontend through to server).
  • a method for anonymously tracking page views.
  • a temporary document name, e.g., a Google sheet generated as the output of a report.
  • resource names in unit tests.
  • identifiers for inspector sessions.
  • identifiers on physical items, such as shipping receipts.
  • identifiers for IoT devices.

Bad implementations of UUID v4 are a risk to developers

Developers who have not been exposed to RFC 4122 might naturally opt to invent their own approaches to UUID generation.

TIFU by using Math.random() is a good discussion of why it’s important that UUIDs are generated using a sound algorithm, with a secure source of randomness.

When I disussed this with a colleague today, they had a great quote:

well I don’t want to write any kind of hash- or crypto-related code even it’s just 40 lines

Folks are excited about this idea

Christoph Tavan and Robert Kieffer the two main maintainers of uuid are excited about the prospect of making RFC4122 UUID generation available to the web and other JavaScript platforms, and have been helping flesh out the proposal.

We just shipped WebCrypto on the Node.js project, and we’re likewise excited to add UUID support as a natual extension to this functionality – we’d love to do so in a platform agnostic way.


Another example of where it would be very nice to have a built in UUID implementation:

My team at Google writes samples that are then embedded throughout documentation, we attempt to ensure that these dependencies have no external dependencies.

I’ve got a PR against that TC39 repo with an updated download count + dependent repo count: https://github.com/tc39/proposal-uuid/pull/39

I also compared it to Lodash’s core module in popularity and usage, and found some interesting findings.