use expo-server-sdk-node types

[reeceyang]

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Summary by CodeRabbit

Release Notes

• New Features
  • Push notifications now support custom icons and rich content (images)
  • Enhanced sound configuration options for notifications with advanced properties

[coderabbitai]

📝 Walkthrough

Walkthrough

This pull request integrates the Expo Server SDK by adding the library as a dependency, replacing custom type definitions with Expo's native types (ExpoPushMessage, ExpoPushSuccessTicket, ExpoPushErrorTicket), and extending notification fields to support icon and richContent properties.

Changes

Cohort / File(s)	Summary
Dependency Addition package.json	Added expo-server-sdk ^5.0.0 as a runtime dependency.
Schema & Type Definitions src/component/schema.ts	Expanded sound field to accept complex objects; added icon and richContent fields; redefined NotificationFields as Omit of ExpoPushMessage excluding "to" field instead of standalone interface.
Implementation Updates src/component/internal.ts	Updated imports to use Expo ticket types (ExpoPushSuccessTicket, ExpoPushErrorTicket); added icon and richContent to notification payload; aligned response typing with Expo's native ticket structure.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 Hopping into Expo's native arms,
With tickets and types full of charms,
Rich icons and content take their flight,
Push notifications glow so bright! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'use expo-server-sdk-node types' directly corresponds to the main changes: importing and using ExpoPushMessage types from expo-server-sdk, updating type definitions, and integrating the new SDK dependency.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch reeceyang/expo-sdk-types

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/get-convex/expo-push-notifications/@convex-dev/expo-push-notifications@37

commit: 59ceab4

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/component/schema.ts (1)

44-44: Add a type-level assertion to prevent NotificationFields and notificationFields validator from silently drifting.

Currently, there's no compile-time constraint linking the NotificationFields type (line 44) to the notificationFields validator (lines 6–42). While they're currently in sync with expo-server-sdk v5, future SDK updates could cause them to diverge undetected. Consider using a satisfies constraint or an Infer type check to ensure any mismatch surfaces at compile time:

export const notificationFields = {
  // ... fields
} satisfies Record<keyof Omit<ExpoPushMessage, "to">, any>;

Alternatively, use Convex's type inference to validate the validator against the type at compile time.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/component/schema.ts` at line 44, The NotificationFields type and the
notificationFields validator can drift silently; add a compile-time constraint
tying them together so mismatches error at build time: change the declaration of
the notificationFields validator (symbol: notificationFields) to use a
TypeScript "satisfies" or a type assertion against the keys of
NotificationFields (symbol: NotificationFields) — e.g. have notificationFields
satisfy Record<keyof NotificationFields, any> or assign it to a helper typed as
Record<keyof NotificationFields, any> — so any added/removed fields between
NotificationFields and notificationFields surface as type errors.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@package.json`:
- Around line 69-71: The package.json currently pins "expo-server-sdk" to
"^5.0.0" which is incorrect; change the version string for the "expo-server-sdk"
dependency to "4.0.0" in package.json, then run your package manager
(npm/yarn/pnpm) to update node_modules and the lockfile; optionally, if the code
only uses the exported type ExpoPushMessage via "import type", consider moving
"expo-server-sdk" to devDependencies after verifying no runtime imports exist,
and ensure tests/build succeed after the change.

---

Nitpick comments:
In `@src/component/schema.ts`:
- Line 44: The NotificationFields type and the notificationFields validator can
drift silently; add a compile-time constraint tying them together so mismatches
error at build time: change the declaration of the notificationFields validator
(symbol: notificationFields) to use a TypeScript "satisfies" or a type assertion
against the keys of NotificationFields (symbol: NotificationFields) — e.g. have
notificationFields satisfy Record<keyof NotificationFields, any> or assign it to
a helper typed as Record<keyof NotificationFields, any> — so any added/removed
fields between NotificationFields and notificationFields surface as type errors.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

expo-server-sdk npm latest version

💡 Result:

The latest npm version of expo-server-sdk (dist-tag latest) is 4.0.0. [1][2]

Install: npm i expo-server-sdk@latest [1]

Sources:
[1] Yarn package page (shows dist-tags and versions) (classic.yarnpkg.com)
[2] UNPKG package.json for v4.0.0 (app.unpkg.com)

Citations:

• 1: https://classic.yarnpkg.com/en/package/expo-server-sdk?utm_source=openai
• 2: https://app.unpkg.com/expo-server-sdk%404.0.0/files/package.json?utm_source=openai

---

Update expo-server-sdk to v4.0.0—v5 is not the current version.

The package specifies "^5.0.0", but the latest version on npm is v4.0.0. Update the dependency accordingly.

The original observation about dependency placement remains valid: only import type is used to reference ExpoPushMessage, so the SDK code is never executed at runtime. If the public type export were decoupled, this could move to devDependencies. However, prioritize the version correction first.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@package.json` around lines 69 - 71, The package.json currently pins
"expo-server-sdk" to "^5.0.0" which is incorrect; change the version string for
the "expo-server-sdk" dependency to "4.0.0" in package.json, then run your
package manager (npm/yarn/pnpm) to update node_modules and the lockfile;
optionally, if the code only uses the exported type ExpoPushMessage via "import
type", consider moving "expo-server-sdk" to devDependencies after verifying no
runtime imports exist, and ensure tests/build succeed after the change.