@tiledev/sdk-apptile-live-selling 0.3.0 → 0.3.1

package/README.md

@@ -11,12 +11,33 @@ native). Your header, comments list, bid bar and sheets stay yours.
 supply, so there is no Shopify dependency.
 
 ```bash
-npm i @tiledev/sdk-apptile-live-selling
+npm i @tiledev/sdk-apptile-live-selling @tiledev/sdk-apptile-live-selling-native
 ```
 
-**One install, two packages.** Everything native — the `LivePip` Expo module, the podspec, the Kotlin,
-the config plugin — lives in `@tiledev/sdk-apptile-live-selling-native`, which this package depends on
-and pulls in for you. This package is pure JavaScript. **You do not list the native one yourself.**
+**Two packages, and an Expo app must list both.** Everything native — the `LivePip` Expo module, the
+podspec, the Kotlin, the config plugin — lives in `@tiledev/sdk-apptile-live-selling-native`. This
+package is pure JavaScript and depends on it.
+
+Listing it separately is not redundant, and this is the one installation mistake worth spelling out.
+**In a tree that contains `expo` and `react-native`, npm nests the native package** at
+`node_modules/@tiledev/sdk-apptile-live-selling/node_modules/…` rather than hoisting it. Expo's
+autolinking scans the whole tree and finds it there quite happily — but its **config-plugin resolver
+resolves plugin names from the project root only**, so `expo prebuild` fails outright:
+
+```
+PluginError: Failed to resolve plugin for module "@tiledev/sdk-apptile-live-selling-native"
+```
+
+A direct entry is what hoists it. Reproduced in a bare project carrying nothing but `expo`,
+`react-native`, `react` and this package.
+
+**Pin it to exactly the version this package's `dependencies` names** — never a different one, or npm
+keeps two copies of the same Expo module and the identical pod and module names collide at link time:
+
+```json
+"@tiledev/sdk-apptile-live-selling": "^0.3.0",
+"@tiledev/sdk-apptile-live-selling-native": "0.1.0"
+```
 
 That split is not tidiness. Expo autolinks any package carrying an `expo-module.config.json` and
 records its **`packageVersion`** in `expoAutolinkingConfig`, which is one of the content sources the
@@ -27,7 +48,8 @@ longer autolinked, so its version is not hashed and a release of it ships as a c
 ### What a version bump here means for you
 
 The native dependency is pinned **exactly**, so the native version can only move when this package's
-version moves. That makes this package's own version number the signal:
+version moves. That makes this package's own version number the signal — and it is why the direct
+entry above can be pinned and left alone until this package's minor changes:
 
 | bump | what it costs you |
 |---|---|
@@ -41,7 +63,8 @@ So take it with a caret and let patches arrive on their own:
 ```
 
 `^0.3.0` accepts every `0.3.x` and refuses `0.4.0` — free JS updates, and a deliberate edit on the day
-native code changes. **Check the fingerprint in CI anyway**: it is the only thing that catches a
+native code changes. On a minor, move the native pin to whatever this package's new `dependencies`
+names, in the same commit. **Check the fingerprint in CI anyway**: it is the only thing that catches a
 mistake here regardless of how the ranges are written.
 
 Peers: `react` and `react-native` are needed by the main entry, which re-exports the React layer;
@@ -63,9 +86,7 @@ beside the root is `./types` (types alone) and a wildcard for any module in `dis
 Every native entry live selling needs lives in a file `expo prebuild` regenerates, so it has to be a
 plugin — an edit by hand works on the machine that made it and silently stops working in CI.
 
-**The plugin ships in the native package**, so name that one in `app.json` even though you never
-installed it directly — it is in your `node_modules` as a dependency of this package, and both Expo's
-plugin resolution and its autolinking scan the whole tree:
+**The plugin ships in the native package**, so name that one in `app.json`, not this one:
 
 ```json
 {
@@ -359,6 +380,12 @@ config plugin:
 4. `npm run build && npm publish`
 5. say in the release notes that a new binary is required
 
+**A documentation-only release of the native package does NOT move the pin.** `0.1.1` was published
+purely to correct its README; the pin here deliberately stays at `0.1.0`. Moving it would have made
+this a native change — consumers on `^0.3.0` take a patch automatically, so their fingerprint would
+have shifted, and every one of them would have needed a new binary to fix a paragraph of prose. The
+version this package pins is a statement about the native *binary*, not about which README is newest.
+
 The minor bump is the whole safety mechanism. A native change released as a patch is the one mistake
 this layout cannot absorb: it moves every consumer's fingerprint without anyone editing anything, and
 the symptom is silent — over-the-air updates simply stop reaching devices.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@tiledev/sdk-apptile-live-selling",
-  "version": "0.3.0",
-  "description": "Live selling, auctions and giveaways for React Native \u2014 the Apptile live-selling gateway as a typed singleton, a Zego room engine behind a platform boundary, an assembled session state machine, and system picture-in-picture with its own config plugin. Commerce comes from an adapter.",
+  "version": "0.3.1",
+  "description": "Live selling, auctions and giveaways for React Native — the Apptile live-selling gateway as a typed singleton, a Zego room engine behind a platform boundary, an assembled session state machine, and system picture-in-picture with its own config plugin. Commerce comes from an adapter.",
   "license": "UNLICENSED",
   "private": false,
   "sideEffects": false,