@mohasinac/appkit 4.54.1 → 4.55.0

package/dist/providers/shipping-shiprocket/index.js

@@ -12,10 +12,19 @@
  *    `loginResponse` requires — the rest are ignored, as Zod ignores unknown
  *    keys by default.
  *
- * 🛑 NOT VERIFIED: every other endpoint. Order creation, AWB assignment,
- *    tracking, serviceability and label generation all MUTATE or bill against
- *    a real carrier account, so none was called. Their field names below are
- *    claims taken from the published docs, not facts read off a payload.
+ * ✅ ALSO VERIFIED (2026-10-20): `GET /courier/serviceability/` from pickup
+ *    `413001`. HTTP 200, and `data.available_courier_companies` came back with
+ *    10-11 entries for Mumbai, Bengaluru and Delhi carrying `courier_name`,
+ *    `rate` and `estimated_delivery_days` — so `serviceabilityResponse` below
+ *    is read off a real payload, not inferred. It is a read-only quote: no
+ *    shipment is created and nothing is booked.
+ *
+ * 🛑 NOT VERIFIED: order creation, AWB assignment, tracking and label
+ *    generation. Each MUTATES or bills a real carrier account — creating an
+ *    order can schedule a pickup, an AWB can consume an allocation, a cancel
+ *    may still bill — so none was called, and none is discoverable without
+ *    incurring it. Their field names below are claims from the published docs,
+ *    not facts read off a payload.
  *
  * That asymmetry is the reason every response is parsed through Zod rather
  * than cast: an unverified contract that is wrong surfaces as a named error at
@@ -312,15 +321,30 @@ export class ShiprocketShippingProvider extends IShippingProvider {
     }
     async checkServiceability(pincode, weight) {
         /*
-         * 🛑 `pickup_postcode` is required by their API and we do not have it on
-         * this contract. Taken from the registered pickup location's name is NOT
-         * possible — it is a nickname, not a pincode — so this returns
-         * "unserviceable" rather than guessing a origin pincode, which would
-         * produce confidently wrong rates.
+         * `pickup_postcode` is required by their API and comes from
+         * `SHIPROCKET_PICKUP_PINCODE`.
+         *
+         * 🛑 This comment used to say "we do not have it on this contract", which
+         * was wrong and cost the whole method: the consumer's `appkit.config.js →
+         * business.registeredAddress` has carried `postalCode` all along. Nothing
+         * set the var, so every call returned `{ isServiceable: false }` WITHOUT
+         * calling the API — checkout would have told every buyer we cannot ship to
+         * them, for every destination. A quote that is silently always "no" is
+         * indistinguishable from a carrier with no coverage, which is why it had no
+         * symptom. Verified live once the var was populated: 10-11 couriers quoted
+         * from 413001 to Mumbai, Bengaluru and Delhi.
+         *
+         * 🛑 appkit has no reader for a consumer config file, so the DEFAULT is the
+         * consumer's job: `src/providers.config.ts` populates this var from the
+         * business block at boot. Deliberately not threaded through
+         * `configurePlatformSupplier` — that seam's own 🛑 says it "is NOT a cache
+         * of site settings and must not become one"; it answers *who the invoice
+         * supplier is*, and a carrier pickup field there is mission creep on a seam
+         * with one stated purpose. One var, one reader, no precedence rule.
          */
         const origin = process.env.SHIPROCKET_PICKUP_PINCODE?.trim();
         if (!origin) {
-            serverLogger.warn("shiprocket: SHIPROCKET_PICKUP_PINCODE unset — serviceability cannot be checked", { pincode });
+            serverLogger.warn("shiprocket: no pickup postcode — set business.registeredAddress.postalCode in appkit.config.js, or SHIPROCKET_PICKUP_PINCODE directly", { pincode });
             return { isServiceable: false, couriers: [] };
         }
         try {

package/dist/seed/faq-seed-data.js

@@ -525,7 +525,7 @@ const faqSeedRecords = [
     {
         id: "faq-emi-installments",
         question: "Can I pay in installments (EMI)?",
-        answer: html(`<p>Yes — on eligible orders. If the seller has EMI enabled and your order with them meets the minimum order value, "Pay in EMI" appears as a payment option at checkout. Choose a tenure of 2–6 months, pay a small token amount upfront, and the remaining balance plus a small monthly surcharge is billed automatically in equal installments each month. Your order ships as soon as the token payment is confirmed — you don't wait for the full amount to be paid.</p>`),
+        answer: html(`<p>Yes — on eligible orders. If the seller has EMI enabled and your order with them meets the minimum order value, "Pay in EMI" appears as a payment option at checkout. Choose a tenure of 2–6 months, pay a small token amount upfront, and the remaining balance plus a small monthly surcharge is billed automatically in equal installments each month. Your order ships once the EMI is fully paid — the token confirms your commitment and secures the item, it is not a dispatch trigger. A seller may opt an individual listing into earlier dispatch, and that is stated on the listing.</p>`),
         category: "orders_payment",
         showOnHomepage: false,
         showInFooter: false,

package/dist/seed/site-settings-seed-data.js

@@ -474,7 +474,7 @@ export const siteSettingsSeedData = {
         minimumTransactionFee: 0,
         gatewayFeePercent: 2,
         codDepositPercent: 10,
-        codHandlingFeeMin: 200,
+        codHandlingFeeCap: 200,
         codHandlingFeePercent: 10,
         // Enabled so a seeded install actually shows the add-ons — see the matching
         // comment on DEFAULT_SITE_SETTINGS_DATA.commissions.

package/dist/seo/json-ld.d.ts

@@ -29,7 +29,14 @@ export interface ProductJsonLdInput {
     price: number;
     currency: string;
     mainImage?: string;
-    images?: string[];
+    /**
+     * Prefer `productImageUrls(doc.images)`. The object form is accepted so a
+     * document holding `ProductImage[]` cannot take the page down — see the
+     * note on `imageUrlOf` in `productJsonLd`.
+     */
+    images?: readonly (string | {
+        url?: string;
+    })[];
     sellerName?: string;
     category?: string;
     status?: string;

package/dist/seo/json-ld.js

@@ -27,7 +27,27 @@ const SITE_NAME = process.env.NEXT_PUBLIC_SITE_NAME ?? "App";
  * an empty value so `JSON.stringify` drops the key rather than emitting `""`.
  */
 function absoluteUrl(value, base = SITE_URL) {
-    const v = value?.trim();
+    /*
+     * 🛑 `unknown` + a typeof test, NOT `string | null | undefined` + `?.trim()`.
+     *
+     * This took production down for hours. The signature said `string`, every
+     * caller type-checked, and then `ProductImage[]` replaced `string[]` on the
+     * product document — so `images.map(absoluteUrl)` received OBJECTS, `?.trim`
+     * was not a function, and the throw escaped into the RSC render and 500'd
+     * `/[locale]/products/[slug]` and `/[locale]/auctions/[id]`: **72 recorded
+     * failures**, the whole page lost to a decorative metadata field.
+     *
+     * A declared parameter type is a compile-time claim about CALLERS. It is
+     * worth nothing at the boundary where data arrives from Firestore, which is
+     * exactly where this function sits — and a schema migration is precisely the
+     * event that makes the claim false everywhere at once.
+     *
+     * So the contract is now behavioural: anything that is not a usable string
+     * is DROPPED, and the key is omitted. JSON-LD is optional enrichment —
+     * losing one image costs a rich-result thumbnail, while throwing costs the
+     * entire page. Those are not close.
+     */
+    const v = typeof value === "string" ? value.trim() : undefined;
     if (!v)
         return undefined;
     if (/^(https?:)?\/\//i.test(v) || v.startsWith("data:"))
@@ -92,11 +112,28 @@ export function productJsonLd(product) {
     const url = `${SITE_URL}${product.detailPath ?? `/products/${product.slug}`}`;
     // Absolutise, then de-duplicate: `mainImage` is very often also `images[0]`,
     // which produced the same URL twice in the emitted array.
+    /*
+     * 🛑 Accepts BOTH shapes on purpose. `absoluteUrl` now drops a non-string
+     * instead of throwing, which stops the 500 — but silently dropping every
+     * image would trade a crash for an invisible loss of the `image` property
+     * that Product rich results REQUIRE. Reading `.url` off an object keeps the
+     * rich result working whichever shape the document holds, so a caller that
+     * forgets `productImageUrls()` degrades to nothing worse than correct.
+     */
+    /*
+     * The cast narrows to `{ url?: string }` rather than `{ url?: unknown }`
+     * (`audit-unknown-leakage` blocks the latter, correctly — an `unknown` in a
+     * member position defeats checking on every read below it). The assertion is
+     * safe without being trusted: `absoluteUrl` tests `typeof value === "string"`
+     * itself, so a document whose `url` is a number is dropped rather than
+     * reaching `.trim()`. Narrow for the compiler, verify at runtime.
+     */
+    const imageUrlOf = (entry) => typeof entry === "string" ? entry : entry?.url;
     const images = [
         ...(product.mainImage ? [product.mainImage] : []),
         ...(product.images || []),
     ]
-        .map((img) => absoluteUrl(img))
+        .map((img) => absoluteUrl(imageUrlOf(img)))
         .filter((img) => Boolean(img))
         .filter((img, i, arr) => arr.indexOf(img) === i);
     return {