uuid should not rely on module load order

[drewthaler]

Is your feature request related to a problem? Please describe.

uuid 7.x uses Crypto.getRandomValues which is not implemented in react-native, and attempts to work around that by asking clients to require another module — react-native-get-random-values — to implement a polyfill. It further caches the polyfill at module load time, requiring users to enforce module load order or else it breaks.

First, relying on module load order is fragile and prone to breakage. In particular, I've run into a problem with Expo where the expo-updates Updates.reloadAsync is reloading our app code in a situation where the uuid module is already initialized — probably because expo-updates uses it.

Second, this causes confusion among developers. At present it's ~10% of the last 32 github issues. (#531, #514, #499).

Describe the solution you'd like

Multiple possible solutions could be implemented. They are not mutually exclusive.

1. uuid could directly rather than indirectly depend on this module that it certainly depends on, importing a symbol and using that, rather than hoping the polyfill gets installed in time.
2. uuid could fold a minimal version of the polyfill code (which is rather simple) into the module and use that as a fallback
3. uuid could lazy-load the getRandomValues symbol on invocation, rather than caching it at module load time. Then at least you just need the polyfill present by the point of use.

Describe alternatives you've considered

See above list. Option 1 seems like the best choice to me, though option 2 would at least restore the pre-7.x functionality. The other two are mainly workarounds for not doing the first one. Relying on module load order is really the core issue, and until uuid stops relying on module load order it will continue to have this problem.

[ctavan]

@drewthaler thank you for raising this. However there are several reasons why we do it the way we do it:

1. uuid could directly rather than indirectly depend on this module that it certainly depends on, importing a symbol and using that, rather than hoping the polyfill gets installed in time.

The biggest use case for this library is still with Node.js and not React Native. Adding a React Native specific polyfill as a dependency in package.json is not an option.

2. uuid could fold a minimal version of the polyfill code (which is rather simple) into the module and use that as a fallback

It was a deliberate decision to drop the insecure random number generator fallback that was present up until uuid@3.x, feel free to read through #173 and related issues (like #354).

3. uuid could lazy-load the getRandomValues symbol on invocation, rather than caching it at module load time. Then at least you just need the polyfill present by the point of use.

This is an option I would like to explore a bit more. Right now we only assign the symbol at module parse time because of the fallback for IE11 msCrypto:

uuid/src/rng-browser.js

Lines 5 to 13 in f3bd455

	// getRandomValues needs to be invoked in a context where "this" is a Crypto implementation. Also,
	// find the complete implementation of crypto (msCrypto) on IE11.
	const getRandomValues =
	(typeof crypto !== 'undefined' &&
	crypto.getRandomValues &&
	crypto.getRandomValues.bind(crypto)) ||
	(typeof msCrypto !== 'undefined' &&
	typeof msCrypto.getRandomValues === 'function' &&
	msCrypto.getRandomValues.bind(msCrypto));

I think we can find a different way where we don't "cache" the symbol on module parse time.

All that said uuid is a general purpose JavaScript library. Unfortunately the React Native runtime does not provide a secure pseudo random number generator, but from my point of view it is out-of-scope for this library to take care of polyfilling.

BTW even Node.js has recently added the WebCrypto API and I think at least for Node.js there's a general tendency to converge the core libraries towards the Web libraries (see e.g. WHATWG URL, Fetch and WebCrypto). So my hope would be that at some point in time React Native also jumps on that train and starts providing a reasonable set of web APIs. Until then I believe the best thing we can do is polyfilling the missing behavior.

I do see the issue of module load order though and I'm happy to accept a pull request that would get rid of the getRandomValues() symbol caching.

[drewthaler]

Thanks for the quick response! I certainly understand, having written code that lives in multiple contexts myself. I'm curious what percentage of installations (users, vs developers) are using uuid in a react-native project. Is there any way to track that? Since Expo uses uuid, it seems possible that the number of RN clients might be much higher than you think. Issues with this code might start trickling in as projects upgrade their dependencies.

I'm not saying that RN should guide the development of uuid simply because Expo depends on it -- but there's a friction there, as this change introduces real problems for react-native users. Anyway, back to the issue at hand:

Lazy-loading the polyfill would just involve pushing the initialization down into the rng() function, something like this:

let getRandomValues;

export default function rng() {
  if (!getRandomValues) {
    getRandomValues = 
      (typeof crypto !== 'undefined' && 
        crypto.getRandomValues && 
        crypto.getRandomValues.bind(crypto)) || 
      (typeof msCrypto !== 'undefined' && 
        typeof msCrypto.getRandomValues === 'function' && 
        msCrypto.getRandomValues.bind(msCrypto));
    if (!getRandomValues) {
      throw new Error(
        'crypto.getRandomValues() not supported. See https://github.com/uuidjs/uuid#getrandomvalues-not-supported'
      );
    }
  }

  return getRandomValues(rnds8);
}

This shouldn't even noticeably slow anything down, as it doesn't add a new branch in the steady-state case. (The if check for initialization runs every time already.)

[ctavan]

Thanks for the quick response! I certainly understand, having written code that lives in multiple contexts myself. I'm curious what percentage of installations (users, vs developers) are using uuid in a react-native project. Is there any way to track that?

Out of curiosity I went back to the analysis I once made for the uuid TC39 proposal where I analyzed the public BigQuery Github dataset.

What I basically did was getting all package.json files from this dataset that have uuid as a dependency and then checking, whether they contain react-native as a dependency as well. The result was:

Has React Native dep?	Count	Ratio
false	6353	0.98
true	122	0.02

So out of all projects in the BigQuery GitHub dataset that declare uuid as a dependency only about 2% seem to be react-native projects.

[drewthaler]

Confirmed the new release works correctly, thanks! It's actually being used by an upstream dependency of ours so I'll push that dependency to adopt it as well.

Regarding the analysis of react-native use, pardon the rabbit hole here, but I was curious and dug into it a little bit. It appears the analysis code is only looking at first-order dependencies, and possibly only some of those? I'm not sure.

I was curious and figured I'd just check how many projects used Expo. Expo is Facebook's preferred fast-and-easy way to use RN, and Expo definitely depends on uuid (by way of expo-constants, expo-location, expo-file-system, expo-notifications, expo-updates, and others),

I took the analysis code and got it running, confirmed that it gave some results for "uuid" dependencies, and then modified it (basically a replace uuid->expo) to look for "expo" dependencies, and dumped the result into a new dataset.

The result was... zero hits.

That's weird because I would have expected, for example, https://github.com/ethantran/react-native-examples to show up in the query as that definitely has a direct dependency on expo. I'm a little stumped here as to what might be going wrong.

But anyway, it's hard to say without hard data, but there are certainly more than 122 expo-based projects on github. :) I think perhaps if you are able to look beyond direct dependencies into indirect dependencies you'll find that there are more RN clients than you might think.

[ctavan]

@drewthaler that's interesting. Would probably require some more investigation. However, whatever the outcome, it would still not convince me to include the RN polyfill as a dependency so probably not worth going down that rabbit hole right now :).

I'll go ahead and publish a non-beta version now so that all RN users can benefit from your fix.