metatroncubeswdev 6598691372 feat: Phase 5 — multi-location, zones, rates, auto-assignment
- Prisma: Zone (postal-code list or radius), Rate (zone- or distance-band
  keyed), GeocodeCache (permanent address->lat/lng cache per
  IMPLEMENTATION_PLAN.md §9), Location.shopifyLocationId (maps to
  Shopify's own Location resource for inventory checks), Booking.zoneId
  (needed for per-zone delivery-density counts, not just per-location).
- app/lib/geo.ts: pure haversine distance + postal-code matching, unit
  tested against known city-to-city distances.
- app/services/zones.server.ts: geocoding (Google Maps Geocoding API,
  cached — never re-geocodes the same address twice), zone eligibility,
  nearest-location auto-assignment ranked by distance, delivery-density
  threshold checks (a sparse zone doesn't unlock until minOrders bookings
  have already routed through it), and inventory-based location exclusion
  via Shopify's InventoryLevel API (locations without a mapped
  shopifyLocationId are left in rather than false-negative excluded).
- app/services/rates.server.ts: pure rate resolution by zone or distance
  band, cheapest-match-wins when bands overlap.
- apps.scheduling.availability.tsx: LOCAL_DELIVERY requests with a
  postalCode/address now auto-assign to the nearest eligible,
  density-qualified zone/location instead of the shop's default location;
  response includes the matched rate. Also fixed a real gap left over from
  Phase 4: this route never actually read Booking counts into
  getAvailability's `consumed` map, so capacity always showed as fully
  available regardless of existing bookings — now it does.
- extensions/datetime-widget: LOCAL_DELIVERY now asks for a postal code
  before showing dates; PICKUP shows a Google Maps pin for the location
  (both gated on an optional Maps API key — a block setting in the theme
  editor, since it needs to be public/client-side, not an app secret);
  confirmation display and cart attributes (dd_zone_id, dd_rate_label)
  carry the resolved zone/rate through to checkout.
- extensions/delivery-customization: now appends the resolved rate to the
  relabeled delivery option ("Local delivery — Aug 25 ($5.99)") when one's
  configured — real Cart Transform-based fee *charging* stays deferred to
  v2 per IMPLEMENTATION_PLAN.md §5.4, this is display-only.
- Admin: /app/zones and /app/rates (Polaris CRUD, mirroring Phase 1's
  patterns), plus shopifyLocationId and auto-geocode-on-save added to the
  location edit form.

Fixed one real bug caught only by `npm run build` (not tsc/vitest, which
both passed clean): app.rates._index.tsx's component called
formatPriceLabel from rates.server.ts, and Remix correctly refuses to
bundle anything imported from a .server.ts path for the client. Moved the
pure (no I/O, no Prisma) formatter to app/lib/currency.ts.

Verified: lint, typecheck, 86 unit tests (+21 new: geo, zones, rates,
delivery-customization's rate-label case with a real WASM fixture run),
16 integration tests against live Postgres (+8 new: geocode caching,
postal/radius zone matching, nearest-first ranking, density thresholds),
both builds, and a live script exercising the full
zone-match -> density-check -> rate-resolve -> availability pipeline
together against the Postgres container.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-24 03:27:21 -04:00

84 lines
2.7 KiB
TypeScript

import { describe, expect, it } from "vitest";
import {
haversineDistanceKm,
isPostalCodeListed,
isWithinRadiusKm,
normalizePostalCode,
sortByDistance,
} from "../../app/lib/geo";
// Known reference distances (verifiable against any mapping service):
const TORONTO = { lat: 43.6532, lng: -79.3832 };
const OTTAWA = { lat: 45.4215, lng: -75.6972 };
const KITCHENER = { lat: 43.4516, lng: -80.4925 };
describe("haversineDistanceKm", () => {
it("is zero for the same point", () => {
expect(haversineDistanceKm(TORONTO, TORONTO)).toBeCloseTo(0, 5);
});
it("is symmetric", () => {
expect(haversineDistanceKm(TORONTO, OTTAWA)).toBeCloseTo(haversineDistanceKm(OTTAWA, TORONTO), 8);
});
it("matches the known Toronto-Ottawa distance within a reasonable tolerance", () => {
// Real-world straight-line distance is ~352 km.
expect(haversineDistanceKm(TORONTO, OTTAWA)).toBeGreaterThan(340);
expect(haversineDistanceKm(TORONTO, OTTAWA)).toBeLessThan(365);
});
it("Kitchener is closer to Toronto than Ottawa is", () => {
expect(haversineDistanceKm(TORONTO, KITCHENER)).toBeLessThan(haversineDistanceKm(TORONTO, OTTAWA));
});
});
describe("isWithinRadiusKm", () => {
it("is true when distance is under the radius", () => {
expect(isWithinRadiusKm(TORONTO, KITCHENER, 200)).toBe(true);
});
it("is false when distance exceeds the radius", () => {
expect(isWithinRadiusKm(TORONTO, OTTAWA, 100)).toBe(false);
});
it("is true exactly at the boundary", () => {
const d = haversineDistanceKm(TORONTO, OTTAWA);
expect(isWithinRadiusKm(TORONTO, OTTAWA, d)).toBe(true);
});
});
describe("normalizePostalCode / isPostalCodeListed", () => {
it("normalizes case and whitespace", () => {
expect(normalizePostalCode("v6b 1a1")).toBe("V6B1A1");
expect(normalizePostalCode(" M5V 3A8 ")).toBe("M5V3A8");
});
it("matches regardless of formatting differences", () => {
expect(isPostalCodeListed("m5v3a8", ["M5V 3A8", "N2G 1A1"])).toBe(true);
});
it("does not match a postal code outside the list", () => {
expect(isPostalCodeListed("K1A 0A6", ["M5V 3A8", "N2G 1A1"])).toBe(false);
});
});
describe("sortByDistance", () => {
it("orders items nearest-first", () => {
const items = [
{ name: "Ottawa", coordinates: OTTAWA },
{ name: "Kitchener", coordinates: KITCHENER },
];
expect(sortByDistance(TORONTO, items).map((i) => i.name)).toEqual(["Kitchener", "Ottawa"]);
});
it("does not mutate the input array", () => {
const items = [
{ name: "Ottawa", coordinates: OTTAWA },
{ name: "Kitchener", coordinates: KITCHENER },
];
const original = [...items];
sortByDistance(TORONTO, items);
expect(items).toEqual(original);
});
});