Version >=7.0.0 is not compatible with React Native / Expo

[dylancom]

When I'm upgrading from 3.4.0 to 7.0.0 an error saying it can't require "crypto" pops up in a React Native app. It used to work fine before.

[VandalPaulius]

+1
v7 isn't compatible with AWS Lambda as well. I get uuid: This browser does not seem to support crypto.getRandomValues(). error, which sounds exactly like @dylancompanjen error

[jvpelt]

Same goes for Azure functions. Getting the message:

uuid: This browser does not seem to support crypto.getRandomValues(). If you need to support this browser, please provide a custom random number generator through options.

[ibc]

Is this just affecting React Native? or also desktop browsers? I have like MANY libs for Node and browser that depends on uuid...

[ctavan]

Thanks for the reports, we‘ll have to investigate.

Could anyone of you provide a minimal reproduction case? That would be extremely helpful!

[ibc]

I just confirm that the issue does NOT happen in browsers (using uuid 7.0.0 with browserify). So it may be something just related to react-native, but I cannot check that.

[TrySound]

Check this
https://github.com/ai/nanoid#react-native

[ctavan]

@TrySound thanks for the hint, maybe we can go a similar route. Will check it out in detail.

[ZebraFlesh]

Could anyone of you provide a minimal reproduction case? That would be extremely helpful!

I think the issue is that node LTS (12.16.1 as of this message) does not offer the crypto.getRandomValues API. Hence anything that uses node (react-native, AWS Lambda, Azure Functions, etc.) will fail. Here's the minimally reproducible test case in a node REPL:

;{
const crypto = require('crypto');
console.log('TLS 1.3: ', crypto.constants.TLS1_3_VERSION); // prove the import works
crypto.getRandomValues();
}

Output:

TLS 1.3: 772
Uncaught TypeError: crypto.getRandomValues is not a function

[TrySound]

@ZebraFlesh You are right getRandomValues is not part of node crypto. Also it's not used in node version.
https://github.com/uuidjs/uuid/blob/master/src/rng.js#L4
getRandomValues is used in browser version and it's correct.
https://github.com/uuidjs/uuid/blob/master/src/rng-browser.js

The problem are environments. They provides own sandboxes.

[ZebraFlesh]

Here's what I know: performing the following code in a serverless handler which is bundled with webpack fails with the crypto.getRandomValues is not a function message:

import { v1 as uuidv1 } from 'uuid';
export const serve = async (event) => {
  const value = uuidv1();
};

Looking at @TrySound's links it's very strange to me that this would go into the browser code instead of the node variant, but it is. (And my webpack config explicitly has a target: 'node' line.)

[TrySound]

Very good catch!

@ctavan main does not always mean node environment and module does not always mean browser environment. There is special browser field for this. You should provide commonjs and esm for both node and browser environment.

Look how this is solved here in react-map-gl project
https://github.com/uber/react-map-gl/blob/master/package.json#L17-L25

[ZebraFlesh]

main does not always mean node environment and module does not always mean browser environment. There is special browser field for this.

Jeez. It took a bit of digging to unpack all that, but you totally nailed it and made me smarter -- so thank you! Here's a link to npm's docs on browser; I couldn't find a concise explainer on module though (looks like it's mostly a proposal that most things are respecting, but not yet formalized in a spec).

[TrySound]

Here's spec
https://github.com/defunctzombie/package-browser-field-spec

Also you can do the same to provide react-native specific solution
https://github.com/ai/nanoid/blob/master/package.json#L30-L32

[TrySound]

"module" field is just a convention. Modern bundlers prefer it over "main". Though node will provide soon conditional exports as official solution.
https://nodejs.org/api/esm.html#esm_conditional_exports