Open m93a opened 2 months ago
Also, if I interpret this thread correctly, the reasons for only exposing crypto.randomUUID
in a secure context is purely "politics" (ie. corporations enforcing what they see as "good practice" on engineers), which kind of sucks IMHO.
We used to have JS implementation of uuid v4, but switched to crypto.randomUUID() in #971. Maybe we can restore that logic as fallback path.
@lucacasonato Do you have opinions to the idea of adding back v4.generate()
function with fallback to js implementation like npm:uuid
does? (https://github.com/uuidjs/uuid/blob/main/src/v4.js)
Is your feature request related to a problem? Please describe.
I love how with jsr.io, Deno's std is on the way to become a true "standard library" for JavaScript. Not having to constantly search for (often abandoned) NPM packages for even the most basic stuff is huge. However, the fact that
@std/uuid
lacks a generator for v4 UUID (the most commonly generated one) is really annoying.My team and I are developing a web app that needs to run on a company's intranet (HTTP on non-localhost address, therefore outside of secure context), so we cannot use
crypto.randomUUID
as recommended by the README.Describe the solution you'd like
A "polyfill" implementation of
v4/generate
that falls back tocrypto.randomUUID
whenever it's available would be awesome.EDIT: That's exactly what
npm:uuid
already does.Describe alternatives you've considered
Right now we are forced to use the
uuid
NPM package for a feature that IMO should be "built in", at least in the standard library.