feat: SDK

[jbroma]

Summary

This PR introduces new package to the project: super-app-showcase-sdk.

It's purpose is three-fold:

• serve as source of truth for dependencies & dev-dependencies necessary for compatibility with the super-app
• provide utilities to use these dependencies easily in other workspaces & external repositories (news-mini-app)
• remove the necessity of keeping shared dependencies in-sync manually by automating the process

With super-apps, managing dependencies quickly gets out of hand and this package is a prototype of a solution that will greatly reduce the overhead caused by the super-app setup and allow for an easier way of maintaining such projects going forward.

Having an SDK in the app allows for easier upgrades and determining compatibility with the host-app based on single variable - SDK version.

We use @rnx-kit/align-deps to align the dependencies. Before syncpack was considered an option but it's only suitable for monorepos, and @rnx-kit/align-deps is more universal in that matter. With a little bit of config, in each package using @rnx-kit/align-deps, we can ensure that requirements are met and the mini-apps will be compatible with the host-app. It can also be used to do a dry-run and perform the check before building for release. This is useful for CI job that might be added to the showcase in the future.

The SDK can be published as an npm package and versioned.

it is It also removed the need to keep dependencies & devDependencies in package.json of the SDK.

SDK contents

The SDK contains the following items:

• resolveNodePackage.gradle - moved from shared directory in the root - dynamic resolution of react-native & RN-CLI location for android (needed for pnpm compatbility)
• react_native_setup.gradle - moved from shared directory in the root - dynamic resolution of react-native & RN-CLI location for iOS (needed for pnpm compatbility)
• shared-dependencies - based on deps.json from the SDK, creates a shared entry for ModuleFederationPlugin and removes the necessity for keeping it up-to-date manually.
• deps.json - list of production dependencies - needs to be maintained manually
• dev-deps.json - list of development dependencies - needs to be maintained manually
• rnx-preset - combines deps.json & dev-deps.json to create a @rnx-kit/align-deps preset used to align the dependencies within the apps.

All relevant packages in the super-app-showcase monorepo were updated to use the SDK.

Checklist

• managing dependencies
• managing devDependencies
• managing shared filed in ModuleFederation plugins
• helper scripts for @rnx-kit/align-deps commands
• publish to npm so it's accessible outside of the monorepo (for the news-mini-app)

Future

The solution created here is quite generic, so it can possibly be extracted into a public npm module that will allow for setup of such SDK repo/package in other projects easily. The only thing that needs to be configurable is the deps.json & dev-deps.json.

When it comes to android and iOS specific scripts - the iOS part is already included in react-native@0.72, while android will most likely be available in react-native@0.74.

Test plan

• host-app, shell-app and dashboard tested locally on iOS
• host-app, shell-app and dashboard tested locally on Android

[jbroma]

After many attempts, I've arrived at conclusion that this approach will not work properly in the long run - this is mostly because this pattern was never supported and creating an umbrella dependency is simply not possible, unless you are willing to handle the resolutions to that nested node_modules one by one.

Instead of removing the direct dependencies and keeping them in the SDK, the SDK will serve a purpose as a control package that will enforce the version of dependencies using a tool called syncpack. Using snapTo version groups functionality, we will be able to control whether all apps using the SDK are using the same versions.

One thing that remains to be determined is whether this solution will work in a polyrepo scenario - or perhaps we need to find another tool to handle dependencies outside of the monorepo. But for monorepo this solution seems very promising and does not deviate from common practices when working with node_modules.

[jbroma]

Reworked the PR description to reflect the newest changes

[jbroma]

published to npm: https://www.npmjs.com/package/super-app-showcase-sdk