Publish @streamcore/react-native-sdk to npm

[jason-shen]

Problem

@streamcore/react-native-sdk is built, documented and usable, and there is no way to install it. package.json says "version": "0.1.1", it has a compiled dist/, a src/ entry for Metro, typed exports, a README and a zh-CN mirror. What it does not have is a public repo or an npm release.

Every other client SDK has one. @streamcore/js-sdk publishes from streamcoreai/js-sdk at 0.1.6, streamcore is on PyPI from streamcoreai/python-sdk, Go installs by import path from streamcoreai/go-sdk, Rust from streamcoreai/rust-sdk. React Native is the only one of the five with nothing behind it.

That gap lands hardest on the audience least able to work around it. For React Native, "vendor the source and point Metro at a path" means fighting the resolver over a TypeScript entry point and a native module, and the Expo majority expect npx expo install to just work. A mobile developer evaluating this project hits a wall the web developer never sees.

Proposed change

Give it the same treatment as the other four: its own public repo, an npm release, and a tag-driven publish so it does not drift again.

The @streamcore scope is already claimed and configured for public scoped publishing — js-sdk ships under it — so the usual blocking step does not apply here.

Repo. streamcoreai/react-native-sdk, mirroring js-sdk: LICENSE, README, README.zh-CN.md, AGENTS.md, and a CI workflow that builds and runs the tests in test/.

Package contents. Verify with npm pack --dry-run before the first publish. Both dist/ and src/ must ship: "main"/"module" point at dist/ while "react-native" and "source" point at src/index.ts for Metro. A files array that drops src/ breaks the Metro path silently, and it will not be caught by anything except a real app.

Peer dependencies. react, react-native and react-native-webrtc belong in peerDependencies with honest ranges, not in dependencies. Getting this wrong yields duplicate native module instances, which fails at runtime with an error message that explains nothing.

Expo. State plainly that this cannot work in Expo Go, since react-native-webrtc is a native module, and document the dev-client path with a config plugin if one is needed. This is the first question every Expo user asks; getting it wrong in the README costs more support time than the publish saves.

Publish workflow. Triggered on a v* tag in the new repo, using npm provenance (--provenance, id-token: write) so the package links back to the commit that built it. streamcoreai/python-sdk's publish workflow is the pattern to mirror.

Smoke test before tagging. A fresh Expo dev-client app that installs the packed tarball and completes a call against a running server. An SDK that has only ever been consumed by path has never had its published shape tested.

Docs. Replace every "clone the repo" instruction with npm install @streamcore/react-native-sdk in the SDK README, the server README's SDK table, and docs/, with the zh-CN mirrors updated in the same change.

Acceptance criteria

• streamcoreai/react-native-sdk is public, with LICENSE, both READMEs, and CI.
• npm install @streamcore/react-native-sdk works from an empty project.
• The published tarball contains dist/, src/, README and LICENSE, and nothing else.
• react, react-native, react-native-webrtc are peer dependencies with correct ranges.
• Expo compatibility documented, including the dev-client requirement.
• Tag-triggered publish workflow with provenance.
• A fresh Expo dev-client app installs the published package and completes a call.
• Server README SDK table and docs/ use the npm install command, zh-CN mirrors included.

Pointers

• streamcoreai/js-sdk — repo layout and exports/files shape to mirror
• streamcoreai/python-sdk — existing tag-triggered publish workflow
• README.md — SDK table listing all five clients
• docs/ — every page that currently tells a React Native user to clone