feat(kno-6559): set up @knocklabs/expo package

[mattmikolay]

Summary

This PR sets up a new package @knocklabs/expo for use with React Native + Expo projects, and moves the existing KnockExpoPushNotificationProvider plus all required Expo dependencies to @knocklabs/expo.

Background

At the moment, @knocklabs/react-native’s package.json includes all Expo-related dependencies as optional peer dependencies:

javascript/packages/react-native/package.json

Lines 43 to 64 in f902b99

	"peerDependencies": {
	"expo": "*",
	"expo-constants": "*",
	"expo-device": "*",
	"expo-notifications": "*",
	"react": "*",
	"react-native": "*"
	},
	"peerDependenciesMeta": {
	"expo": {
	"optional": true
	},
	"expo-constants": {
	"optional": true
	},
	"expo-device": {
	"optional": true
	},
	"expo-notifications": {
	"optional": true
	}
	},

However, KnockExpoPushNotificationProvider.tsx imports these dependencies using static imports:

javascript/packages/react-native/src/modules/push/KnockExpoPushNotificationProvider.tsx

Lines 7 to 9 in f902b99

	import Constants from "expo-constants";
	import * as Device from "expo-device";
	import * as Notifications from "expo-notifications";

This causes build errors when Metro (the bundler used by React Native) bundles an application that depends on @knocklabs/react-native but does not include Expo dependencies.

It’s possible to refactor KnockExpoPushNotificationProvider to import Expo modules dynamically using require. Support for loading optional dependencies via require was added to Metro v0.59.0 by facebook/metro#511.

However, optional dependencies in React Native are subject to some longstanding issues, e.g. facebook/metro#836 and facebook/metro#1256. (And sure enough, during my testing locally, I encountered these issues.) Even if we load Expo modules using require and avoid these bugs, it’s highly likely future refactoring of the code would cause the build errors to occur again. For this reason, we feel it’s safer to migrate all code in @knocklabs/react-native that relies upon Expo to a new Expo-specific SDK.

Testing

I tested everything locally and confirmed the following:

• Both @knocklabs/react-native and @knocklabs/expo successfully receive notifications via KnockFeedProvider
• Push notifications are successfully received via the KnockExpoPushNotificationProvider after moving it to the @knocklabs/expo package
• The build issues previously caused by Expo module imports in @knocklabs/react-native have been fixed

[changeset-bot]

🦋 Changeset detected

Latest commit: 30f6c35

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 3 packages

Name	Type
@knocklabs/react-native-example	Minor
@knocklabs/react-native	Minor
@knocklabs/expo	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
javascript-nextjs-example	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 14, 2024 9:13pm
javascript-slack-connect-example	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 14, 2024 9:13pm
javascript-slack-kit-example	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 14, 2024 9:13pm

[linear]

KNO-6559 [React Native SDK] Ensure Expo is not a required dependency

[cjbell]

one q

[cjbell]

Just to confirm, is this right for the initial version? Do we not want to start at 0.1.0?

[mattmikolay]

We can definitely start at v0.1.0. I wasn’t sure what’s preferable: restarting version numbering at 0 since this is a new package, or starting with the same version number as our RN SDK since the new package is essentially a fork.

[mattmikolay]

I’ll set the version attribute here to 0.0.0, so that when changesets bumps the version code, the first release will be 0.1.0.