feat(NODE-4927): exports in package.json for react native and document how to polyfill for BSON

[nbbeeken]

Description

What is changing?

Add react-native exports specifier.
Set it to the commonjs bundle.
Document polyfills.

What is the motivation for this change?

To support react native.

Double check the following

• Ran npm run lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[kraenhansen]

I'm not 100% sure on this, but I think the react-native property should be one level up, looking at the docs for the Metro config and the spec that it references.

Was this manually tested in a React Native project?

[nbbeeken]

Yes, I made a new project with react-native-cli and confirmed that this works with the bundling that comes with that setup, not sure if that is Metro. The "exports" property is standardized for nodejs, webpack, and rollup, I suspect it may just not be explicitly mentioned there?

We can get this into an alpha release and maybe you have projects with more diverse tooling worth testing to see if it gets pulled in correctly, I'll ping you on slack when its available

[kraenhansen]

I have concerns about the need for end-users to provide these polyfills.

[kraenhansen]

It would be great if these could be included in the React Native bundle though.

I don't think it's too much to warn users and have them optionally import the react-native-get-random-values package for added security, but having these polyfills as strict requirement for React Native users (hence all Realm JS users) is a no-go in my opinion.

[baileympearson]

That's a valid concern.

@nbbeeken would know better than I about the difficultly of bundling these the required dependencies in the react native build.

As an alternative, could realm provide these polyfills for users instead of BSON?

[nbbeeken]

Let's file a ticket for providing a polyfilled bundle for RN and we can fill it out with more detail on how the bundle should behave given that there is a mix of platforms and javascript engines that can be combined here.

Just adding background, one of our goals was to move away from bundling polyfills since they became part of the semantic version of this package despite being outside of our control. We became unable to pull in updates to the polyfills as they would break existing users but prevented other users from puling in the needed updates. Keeping polyfilling outside of a library's responsibility understandably adds friction but allows those that need the specific APIs working in a specific way to have control over that since not every polyfill is perfect for every use case.

[kraenhansen]

I understand that problem, we have similar issues in the Realm JS package. Ideally the bson package's source code should be runtime independent and therefore not rely on these globals in the first place. Instead it could have these functions "injected" by a platform specific index.ts wrapping the actual library. We're doing similar tricks on the upcoming refactor of the Realm JS SDK.

Technically the base-64 package could be a peer dependency and not included in the bundle, while it's still being imported by bson and injected into the "common" part of its code.