tile-modules

Type-safe SDK for the three Apptile pillars — analytics, integrations, notifications — consumable from React Native (web, iOS, Android) and Node.

This package ships under a dual-build model:

| Build | What's in it | Distribution | | ----------- | ----------------------------------------- | ------------ | | public | Type definitions + no-op stubs that return believable mock data | Published to npm; what 3rd-party app developers integrate against | | internal | Real implementations (HTTP, batching, caching, push-token plumbing) | Bundled into Apptile's own apps; not published |

The two builds share one source of truth for types (src/types/), so neither side can drift.

Top-level exports

import {
  apptileAnalyticsCore,
  apptileIntegrationsCore,
  apptileNotificationsCore,
  // or as namespaces:
  analytics, integrations, notifications,
} from '@apptile/tile-modules';

Or per-domain:

import { apptileAnalyticsCore } from '@apptile/tile-modules/analytics';
import { apptileIntegrationsCore } from '@apptile/tile-modules/integrations';
import { apptileNotificationsCore } from '@apptile/tile-modules/notifications';

Types alone:

import type { AnalyticsEvent, ApptileAnalyticsCore } from '@apptile/tile-modules/types';

Surface

| Domain | Core object | Methods | | --------------- | ---------------------------- | -------------------------------------------------------------------- | | analytics | apptileAnalyticsCore | init, track, identify, screen, flush, reset, isReady | | integrations | apptileIntegrationsCore | init, list, get, call, isReady | | notifications | apptileNotificationsCore | init, requestPermission, getPermissionStatus, registerPushToken, getInbox, markRead, onReceive, isReady |

The signatures are identical across the public and internal builds — only the bodies differ.

File layout

src/
├── types/                                    # shared types (both builds)
│   ├── analytics.ts
│   ├── integrations.ts
│   ├── notifications.ts
│   └── index.ts
├── analytics/
│   ├── apptileAnalyticsCore.public.ts        # stubs returning mock data
│   ├── apptileAnalyticsCore.internal.ts      # real impl
│   ├── index.public.ts                       # re-exports the .public file
│   └── index.internal.ts                     # re-exports the .internal file
├── integrations/   ...same shape...
├── notifications/  ...same shape...
├── index.public.ts                           # public-build root entry
└── index.internal.ts                         # internal-build root entry

tsconfig.public.json excludes every *.internal.ts and index.internal.ts; tsconfig.internal.json excludes every *.public.ts and index.public.ts. The two builds emit to dist/public/ and dist/internal/ respectively.

Builds

npm run build:public    # → dist/public/    (publishable)
npm run build:internal  # → dist/internal/  (consumed by 1st-party apps)
npm run build           # both

npm publish runs prepublishOnly which builds only the public tree. .npmignore then strips any *.internal.ts files and dist/internal/ from the published tarball, just in case.

React Native compatibility

Source files use only universal APIs (fetch, setInterval). No Node built-ins. Metro can consume src/ directly — see react-native in package.json's exports.

For platform-specific behaviour (FCM/APNs prompts, Expo notifications, etc.), the consuming app wires the OS-level hooks; this SDK keeps the API abstract.

Adding a new function

1. Add the signature to the relevant interface in src/types/.
2. Add a stub returning mock data to src/<domain>/<thing>.public.ts.
3. Add the real impl to src/<domain>/<thing>.internal.ts.
4. Re-export from both index.public.ts and index.internal.ts if it's a new top-level symbol.

That's it — both builds will compile because the shared types live in one place.