Skip to content

Lander-Parren/types-blueconic-react-native

Repository files navigation

@landerp/blueconic-react-native-types

Unofficial TypeScript definitions for @blueconic/blueconic-react-native.

Not affiliated with or endorsed by BlueConic. The upstream SDK is commercially licensed — these types describe its public JavaScript API only and do not redistribute any upstream code.

Install

pnpm add -D @landerp/blueconic-react-native-types
# or
npm install --save-dev @landerp/blueconic-react-native-types

Usage

The package augments the @blueconic/blueconic-react-native module declaration, so once installed, normal imports of the upstream package pick up the types automatically — no import changes needed in your code:

import BlueConicClient, {
  BlueConicConfiguration,
  EventName,
} from "@blueconic/blueconic-react-native";

const config = new BlueConicConfiguration.Builder()
  .setHostName("https://example.blueconic.net")
  .setDebug(true)
  .build();

BlueConicClient.initialize(config, (err) => {
  if (err !== null) {
    // handle init error
  }
});

const profileId = await BlueConicClient.getProfileIdAsync();
BlueConicClient.setProfileValue("email", "user@example.com");
BlueConicClient.subscribe(EventName.PropertiesDialogue, false, "sub-1");

If TypeScript doesn't pick up the augmentation automatically (common when your tsconfig.json excludes node_modules, as most do), reference the package from one of your project's declaration files.

In a .ts or .tsx file — or a .d.ts that is already a module:

import "@landerp/blueconic-react-native-types";

In an ambient .d.ts file (one without top-level import/export, e.g. an Expo project's declarations.d.ts), use a triple-slash reference so the file stays a script and sibling declare module blocks keep working:

/// <reference types="@landerp/blueconic-react-native-types" />

All 78 native methods from the iOS/Android bridge are typed, each in its sync / Async / WithCallback variants.

Versioning

The package version tracks the upstream SDK's major.minor — e.g. 5.2.x covers upstream 5.2.x. Patch bumps on our side are free to change purely for type fixes.

Keeping types in sync with upstream

A sync script detects BlueConic API changes automatically:

pnpm sync           # prints diff vs committed snapshot (exits 1 on drift)
pnpm sync:write     # writes new snapshot + bumps package.json to match upstream

A scheduled GitHub Actions workflow (.github/workflows/upstream-check.yml) runs this weekly and opens a PR when BlueConic's API surface changes. After merging, update index.d.ts to reflect the diff.

Releasing

Releases are fully automated by release-please + Conventional Commits:

  1. Commits land on main with Conventional Commit prefixes:
    • feat: — new typings or capabilities (minor bump)
    • fix: — type corrections (patch bump)
    • feat!: / fix!: / BREAKING CHANGE: — major bump
    • chore:, docs:, refactor: — no release
  2. Release Please opens (or updates) a Release PR that bumps package.json + regenerates CHANGELOG.md.
  3. Merging the Release PR:
    • Tags vX.Y.Z
    • Creates a GitHub Release with the generated changelog
    • The tag push triggers publish.yml, which publishes to npm with provenance.

No manual version bumps, no manual npm publish.

Contributing

  1. Fork, branch, edit index.d.ts and blueconic__blueconic-react-native-tests.ts.
  2. Run pnpm test — must pass with zero errors under strict mode.
  3. Commit using Conventional Commits (feat: add X, fix: correct Y).
  4. Open a PR. CI runs pnpm test on every push and pull request.

License

MIT — see LICENSE. The upstream SDK retains its own commercial license.

About

Unofficial TypeScript definitions for @blueconic/blueconic-react-native

Topics

Resources

License

Stars

Watchers

Forks

Packages

 
 
 

Contributors