Google sign in for React Native: the funding field points at the paid product

The funding field points at the commercial product, not at a sponsor page

The manifest has a funding field, and its value is the URL of the paid version the README spends a section on. That is a deliberate choice by the project rather than an accident, and it tells you where the author expects the value to flow.

Two other manifest facts sit next to it. The version is 16.1.5, which matches the newest tag. And the package name is scoped, `@react-native-google-signin/google-signin`, while the repository name carries the same string unscoped. Those two badges at the top of the page both point at the scoped name on npm.

The entry points are declared three ways: a module build for runtime, a types entry under a typescript directory, and a source entry pointing into `src`. The exports map serves the same two runtime values and additionally exposes two files by path, the Expo plugin file and the package manifest itself, so a tool that needs to read either can resolve them through the package rather than by reaching into node_modules.

The free version's whole description is one sentence about a legacy SDK

The package introduces itself in a single line: it provides Google authentication for React Native and Expo apps. Then come the two sentences that matter. This is the free, public version. It supports Android and iOS, and it uses the legacy Google Sign-In SDK on Android.

That clause is the whole of the differentiation for anyone choosing between this and something else, and it is stated as a fact rather than as a warning or a plan. Nothing on the page says when the legacy SDK will stop working, and nothing says what a non-legacy path would look like inside this package.

After it there is a link to the full documentation, pointing at an install page under the project's documentation site. So the entire free-package story on the front page is two sentences and an outbound link, while the rest of the page is about something else.

The premium section is longer than the free package's entire description

Everything after that link is a pitch. It opens by asking whether you are looking for a modern implementation not relying on deprecated APIs, and for web or macOS support, and answers by naming a different product as the premium version of the same package, built on modern Google identity APIs.

Then five bullets: cross-platform across Android with Credential Manager, iOS, web and macOS from a single API; a configuration doctor command line tool; automatic configuration parameter detection; advanced security with custom nonce support and iOS App Check; and a maintenance promise worded as your purchase keeping the package up to date with new Expo and React Native releases.

Below them are two claims about the audience, one million plus npm downloads and trust from indie hackers through large teams. Then two links, one to a licence page and one to what is included, and the second of those points back at the free package's own documentation with an anchor appended to it.

The paid pitch is written in setup time, not in API capability

Read the bullets closely and three of the five are about configuration rather than about what the library can do at runtime. The configuration doctor is a command line tool that diagnoses Android configuration issues, and the claim attached to it is that this saves hours otherwise lost to `DEVELOPER_ERROR`, which is the error string Android surfaces when a Google services configuration is wrong. Automatic configuration parameter detection is the same subject again, framed as faster setup.

Only the security bullet and the platform bullet describe things the free package cannot do: custom nonce support and iOS App Check, and the two platforms beyond Android and iOS.

So the free package's stated limitation, the legacy Android SDK, and the premium product's headline are the same subject from two directions. The implication for anyone evaluating this is simple: if the setup is already working on the legacy path, the remaining value of the paid product is web, macOS, and the newer identity APIs.

prepare runs three builds and installs hooks, and it runs on install

The build script is worth reading because of where it sits:

"prepare": "bob build && yarn build:plugin && yarn build:mock && husky install",
"release": "yarn prepare && npx semantic-release",

The prepare hook builds the library with bob, then compiles two additional TypeScript projects, one for the Expo config plugin and one for the test mocks, and then installs git hooks. Because prepare is the hook npm and Yarn both run during an install, a plain install of this package into a project performs three builds and writes hooks into the repository it is being installed into.

The release script runs that same chain again and then hands off to semantic-release, which it invokes through npx rather than from a pinned dependency. Elsewhere the scripts cover the usual ground: linting over JavaScript and TypeScript, a types-only check with emit turned off, a Jest run with one environment variable set, launch scripts for both platforms, a pods script that installs into the example app, and a bootstrap script that chains the example install, the root install and the pods step.

The published file list names a cpp directory the repository does not have

The files list decides what reaches npm, and one of its entries has no counterpart at the top of the repository. It names `cpp` alongside `src`, `lib`, `android`, `ios`, `expo` and the podspec, and the tree of thirty-three top-level entries has no cpp directory.

The rest of the list is shaped to keep development material out of the package. Three negative patterns exclude tests, fixtures and mocks wherever they appear, and two more exclude the build directories under android and ios. The plugin and the Jest helper are still shipped, but only in built form, as `plugin/build` and `jest/build`, which is why the prepare hook compiles them. The example application is excluded by a narrower pattern that drops one directory inside the typescript output.

So what a consumer receives is compiled JavaScript, compiled type declarations, the native sources for both platforms, the Expo module and its plugin, and the readme, and nothing that would let them run the tests.

TypeScript in, a Flow declaration out, and four plugin surfaces

The recorded language is TypeScript and the manifest points its source entry at a TypeScript file, with two configs at the root for the general build and for the build output. There is also a Flow declaration file at the root of the repository, so the package carries type information in both systems.

The tooling is layered. Yarn is set up in the checked-in cache style, with a Yarn directory and a Yarn configuration file at the root next to the lockfile. Formatting and linting have separate configuration files, and there are separate ones for Babel, Metro, the React Native CLI and Jest, plus a release configuration file. A Prettier script covers Markdown alongside JavaScript and TypeScript.

The integration surfaces are four. There is an Android directory and an iOS directory with a CocoaPods podspec beside them, an Expo directory with a module configuration file, and a plugin directory whose compiled output is published. The example application and an image directory sit alongside those. There is no changelog file at the root, and two of the three recent tags, v16.1.3 and v16.1.4, were published about two hours apart on the same evening.

Editorial conclusion

Adequate fit: a React Native or Expo project that needs Google sign in on Android and iOS today, is willing to ship against the legacy Android SDK, and reads the linked documentation before configuring it. It fits badly for a project that needs web or macOS, and it fits badly for a project already configured around modern Google identity APIs, because neither is in the free package. Four things are worth checking before adopting it. The free version is built on a legacy Android SDK, which is the project's own description. The manifest sets its funding field to the commercial product's site. The prepare script runs three builds and installs git hooks, and it runs as part of an install. And the published file list includes a `cpp` entry with no matching directory at the top of the repository. Nothing above was installed, built or run.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-native-google-signin/google-signin on GitHub
4. README
5. Releases