Align SDK tsconfig lib with React Native

[ofalvai]

Why

tsconfig.build.json declares only the es6 lib, but it has no types setting. So TypeScript loads every @types/* package in node_modules, and @types/node adds its own ES2018 libs and Node globals. The lib setting has no effect. Code can use APIs outside it and still compile.

This came up in #63, which uses Object.entries (ES2017). That build passed only because of @types/node. This PR fixes the config first, and #63 builds on top of it.

What changes

• lib is now the list from @react-native/typescript-config@0.76.0. RN 0.76 is the oldest version we support, and this list is RN's own statement of the runtime APIs available there.
• "types": [] stops the build from loading ambient types, so the lib list is actually enforced.
• src/globals.d.ts declares console.log, the one RN runtime global the SDK uses.

The emitted lib/ output is the same as before.

Decisions

• Copy the lib list instead of extending the official config. @react-native/typescript-config is made for apps. It sets noEmit, bundler module resolution and ESM output. We emit CommonJS .js and .d.ts files, so we would have to override about half of it.
• A small globals file instead of "types": ["react-native"]. The official config gets console from the RN types. RN 0.87 (our devDependency) exposes its types only through package.json exports, and TypeScript 4.9 with moduleResolution: "node" cannot resolve them. globals.d.ts has a TODO to remove it after the build moves to TypeScript 5.

Out of scope

• Moving the build to TypeScript 5 and bundler resolution, or to react-native-builder-bob (see AGENTS.md). Extending the official config makes sense at that point.
• The minimum RN version (0.76) is written only in the README and docs. Nothing in package.json declares or tests it.

🤖 Generated with Claude Code

[Copilot]

Copilot review overview

🟢 Approval recommended

All reviewed changes are focused and no unresolved issues were identified.

Review effort: Balanced
Findings: None

What changed in this PR

Aligns the SDK’s TypeScript build with React Native 0.76 runtime APIs while preventing ambient Node typings from widening available globals.

Changes:

• Matches React Native’s supported ES libraries.
• Disables automatic @types/* inclusion.
• Adds a narrow console declaration.

File	Description
tsconfig.build.json	Restricts TypeScript libraries and ambient types.
src/​globals.d.ts	Declares the required React Native console global.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[zoltanszabo-bitrise]

Do we use any of these? We can handpick the ones we want to use in the SDK, and what RN support. The SDK can be stricter than RN!

If we dont use anything from this big list, simply keep our list simple as can be: [es2019] for example.
And I would keep a link to the RN's list of the minimum supported version for sure, for easier lookup if we ever want to widen it.

[ofalvai]

Sure, why not, fixed: https://github.com/bitrise-io/react-native-code-push/compare/64395e699fe917282a436120b45aace1d600402b..c93b49a1130ef25c6a27c32d2fb6f866d06b138d

[zoltanszabo-bitrise]

@ofalvai Additional questions:

• Do newer RN versions have wider JS support?
• Do we know what RN version most of the CodePush users are on?
• Why is RN 0.76 the minimum we support?
• Are we planning to go with a newer stricter min RN version later?

[ofalvai]

@zoltanszabo-bitrise

Do newer RN versions have wider JS support?

If you mean polyfill support, then yes. Perfect example from my main PR: https://github.com/bitrise-io/react-native-code-push/pull/63/changes#diff-3846a333c5be87762e72c131ab62f5015d1777f1c6c00fa4af419f07dc0dc6bfR294-R296

Do we know what RN version most of the CodePush users are on?

At the moment, we don't. I think we can be generous and support old versions as long as it doesn't have too much of an overhead for us, and decide case-by-case.

Why is RN 0.76 the minimum we support?

It comes from README.md and from the pre-fork state of things. Adding support for RN New Architecture meant breaking changes, so that first verison of the SDK cut support for older RN versions.

Are we planning to go with a newer stricter min RN version later?

Definitely, 0.76 is now 2 years old, I think we can start bumping this, but it's hard to say how aggressively.