@getmicdrop/venue-calendar 4.2.0 → 4.2.2

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@getmicdrop/venue-calendar",
   "_version_comment": "4.1.55 was the last PUBLISHED version, and the tree carried 36 commits npm's 4.1.55 does not have — including the gate-password security fix and four money fixes. A filename must never reuse a version npm has taken (jsDelivr/unpkg cache the FIRST bytes they see under `@4.1.55` forever, so republishing that number ships the old widget to every venue that pinned it). Bumped to 4.2.0 here, BEFORE anything is built for publish. `npm run release:preflight` refuses to proceed when this number already exists in the registry.",
-  "version": "4.2.0",
+  "version": "4.2.2",
   "description": "A customizable Svelte calendar component for displaying comedy events",
   "type": "module",
   "types": "./dist/types/index.d.ts",
@@ -142,7 +142,7 @@
   "homepage": "https://github.com/get-micdrop/venue-calendar#readme",
   "_peerDependencies_comment": "TWO different contracts live here, and they cover DIFFERENT entry points. (a) `svelte` — the ES and UMD builds externalize svelte (vite.config.lib.js rollupOptions.external) and ship PRE-COMPILED output that binds through svelte/internal/client, a private, non-semver surface. So the consumer's svelte is the runtime for code this package's compiler emitted, and the compiler version is the real floor. The upper bound is the part that was missing: `>=5.56.0` admits Svelte 6, and this was the ONLY manifest in the fleet that would have taken it — svelte-stripe's `svelte: ^5` peer was the sole accidental brake, and moving that package to devDependencies (below) removes it, so the bound has to be explicit and it has to land in the same change. The floor is 5.56.4, NOT the 5.56.9 this repo compiles with: micdrop-frontend pins svelte to exactly 5.56.4 tree-wide and CANNOT move (mf 3ce86e22a reverted the 5.56.4 -> 5.56.9 bump because the Foundry Catalog Gate stops producing a byte-identical catalog under a different compiler, and that has to be fixed with the catalog regenerated in the same change, on Linux). A floor of 5.56.9 would therefore ERESOLVE against micdrop-frontend's own override on `npm ci` — i.e. it would brick the app that consumes this package in order to record an aspiration. The residual skew (consumer 5.56.4 < compiler 5.56.9) is real but not a missing-symbol crash: all 73 svelte/internal members the shipped dist references are present in 5.56.4. The exposure is SIGNATURE drift across the 7 differing internal/client files (reactivity/props.js `rest_props` is the one behind the June crash), which export-presence checks cannot catch. Close it by aligning the compilers, not by widening this range. (b) `@getmicdrop/svelte-components` — required by the ./api subpath ONLY: dist/api/api.mjs emits 5 SC subpath imports and api.cjs emits 7 (vite.config.api.js externalizes SC deliberately; the manifest never said so, and npm therefore never installed or warned about it). It is marked OPTIONAL below on purpose: @getmicdrop/venue-calendar is PUBLIC on npm but @getmicdrop/svelte-components is PRIVATE (an unauthenticated `npm view` of it 404s while this package resolves fine), so a REQUIRED peer would make `npm i @getmicdrop/venue-calendar` fail outright for every third party that only wants the widget entry — which bundles SC and needs nothing installed. Optional means npm stays quiet when SC is absent (it cannot be fetched anyway) but still version-checks it when present. The main/IIFE/UMD builds do NOT externalize SC; see the devDependencies pin. TODO(seam): declaring SC in BOTH devDependencies (build) and peerDependencies (./api contract) is the intended shape, but it turns scripts/lockfile-sync-check.test.js RED — its `scDepType` helper asserts SC appears in EXACTLY ONE of the four dependency maps and now finds two, failing 3 tests. The detector itself (scripts/lockfile-sync-check.mjs) handles peers correctly and is green; only the test's assumption is stale. Fix there, not here: have `scDepType` search the INSTALL-time maps only (dependencies/devDependencies/optionalDependencies), since a peer is a declaration about the consumer's tree rather than about what this lockfile installs.",
   "peerDependencies": {
-    "@getmicdrop/svelte-components": "^6.24.311",
+    "@getmicdrop/svelte-components": "^6.24.313",
     "svelte": ">=5.56.4 <6"
   },
   "peerDependenciesMeta": {
@@ -154,14 +154,14 @@
   "_devDependencies_pin_comment": "Three EXACT pins in here are load-bearing and must not be re-caretted by a dependency bot. (1) `@getmicdrop/svelte-components` — the ES/UMD/IIFE builds do NOT externalize SC, so it is COMPILED INTO every shipped artifact. Under `^6.24.311` the SC version a venue's browser executes is whatever the range floats to on the publish machine at publish time, which is not recorded anywhere and is not reproducible after the fact; the `overrides` block below cannot help (it only ever covered esbuild, and consumers ignore a dependency's overrides entirely). Pinned exact so the artifact and the manifest agree, and vite.config.lib.js stamps the resolved version into the bundle as __VC_SC_VERSION__ so a venue's devtools can answer 'which SC is this?'. (2) `svelte` — the compiler whose private internal/client calls the pre-compiled dist binds to. `^5.56.9` let the compiler move under a peer range that stayed still; see _peerDependencies_comment. (3) `@stripe/stripe-js` in dependencies — see its own note there.",
   "devDependencies": {
     "@eslint/js": "^10.0.1",
-    "@getmicdrop/svelte-components": "6.24.311",
+    "@getmicdrop/svelte-components": "^6.24.313",
     "@playwright/test": "^1.60.0",
     "@size-limit/file": "^13.0.3",
     "@sveltejs/adapter-auto": "^7.0.1",
     "@sveltejs/kit": "^2.70.2",
     "@sveltejs/vite-plugin-svelte": "^7.3.0",
     "@tailwindcss/vite": "^4.3.3",
-    "@tanstack/svelte-query": "6.1.33",
+    "@tanstack/svelte-query": "6.1.38",
     "@testing-library/jest-dom": "^7.0.1",
     "@testing-library/svelte": "^5.3.1",
     "@types/node": "^26.2.0",
@@ -196,7 +196,10 @@
   },
   "_overrides_comment": "esbuild is not a direct dependency here — it arrives as an OPTIONAL PEER of vite (^0.27.0 || ^0.28.0) and of unplugin-dts (*), and npm resolved it to 0.27.3, which is inside GHSA range 0.27.3-0.28.0 (arbitrary file read via the dev server on Windows; dev-only exposure, but this is a Windows shop). There is no direct dependency to bump, so the lift has to be an override. Keep this satisfying vite's peer range — ^0.28.x does; a 0.29 line would not.",
   "overrides": {
-    "esbuild": "^0.28.2"
+    "esbuild": "^0.28.2",
+    "svelte": "5.56.9",
+    "@tanstack/svelte-query": "6.1.38",
+    "@tanstack/query-core": "5.101.4"
   },
   "_dependencies_comment": "`@stripe/stripe-js` is pinned EXACT, and the caret it replaces was not a style choice. loadStripe() does not fetch a versioned URL — it builds `https://js.stripe.com/<RELEASE_TRAIN>/stripe.js` from a CONSTANT baked into whichever @stripe/stripe-js version resolves (9.13.0 hardcodes `RELEASE_TRAIN = 'dahlia'` in dist/index.mjs). This widget runs on third-party venue sites, many of which allowlist that exact script URL in their CSP, so a caret means a routine transitive bump silently MOVES the file a venue must allowlist and checkout dies on their site with a CSP violation and no signal on our side. The live 4.1.55 bundle still requests /clover/stripe.js while this tree resolves to /dahlia/ — the drift is not hypothetical. Pin it, and when the pin is raised, put the new train in the release notes so venue CSPs can be updated first. `svelte-stripe` USED to live here and has moved to devDependencies: no shipped artifact reaches it (dist mentions it only inside .map sourcesContent), CheckoutForm.svelte:81 deliberately calls Stripe.js directly instead ('Svelte 5 compatibility bug'), and the sole live import is a dynamic `import('svelte-stripe')` in src/routes/v/[venueSlug]/gift-cards/purchase/+page.svelte — a SvelteKit route in the dev/e2e app, which `files` does not publish. It stays installed for dev; it just stops being something every npm consumer downloads. Note what that move COSTS: svelte-stripe's own `svelte: ^5` peer was the only thing bounding a consumer's svelte below 6, so peerDependencies.svelte gained an explicit `<6` in the same change.",
   "dependencies": {