@shipstatic/ship 3.4.0-beta.3 → 3.4.0-beta.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/THIRD-PARTY-LICENSES.md +1 -1
- package/dist/browser.d.ts +38 -6
- package/dist/browser.js.map +1 -1
- package/dist/cli.cjs.map +1 -1
- package/dist/index.cjs.map +1 -1
- package/dist/index.d.cts +38 -6
- package/dist/index.d.ts +38 -6
- package/dist/index.js.map +1 -1
- package/package.json +2 -2
package/THIRD-PARTY-LICENSES.md
CHANGED
package/dist/browser.d.ts
CHANGED
|
@@ -734,8 +734,9 @@ type AccountPlanType = (typeof AccountPlan)[keyof typeof AccountPlan];
|
|
|
734
734
|
* "unlimited" — so no consumer needs an "is it bounded?" branch. A cap of `0`
|
|
735
735
|
* means the plan does not have the feature at all; a cap of `N` bounds
|
|
736
736
|
* creation, and what an account already holds above a cap stays until a plan
|
|
737
|
-
* TRANSITION fits it
|
|
738
|
-
*
|
|
737
|
+
* TRANSITION fits it: excess domains are paused, newest first, and members
|
|
738
|
+
* are paused together while the account holds more than its cap. Deployments
|
|
739
|
+
* never pause; above their cap they only block creation.
|
|
739
740
|
*
|
|
740
741
|
* A count is an aggregate over a collection, so it lives on the summary
|
|
741
742
|
* resource that owns the collection: `GET /account` for one caller, `GET
|
|
@@ -941,10 +942,12 @@ interface Account {
|
|
|
941
942
|
* from where the account stands. It excludes the plan and cadence the
|
|
942
943
|
* account already holds and the one move the door refuses, a dearer tier
|
|
943
944
|
* at a shorter interval (an immediate move would mint a proration credit,
|
|
944
|
-
* a deferred one would make a customer asking for more wait a year).
|
|
945
|
-
*
|
|
946
|
-
*
|
|
947
|
-
*
|
|
945
|
+
* a deferred one would make a customer asking for more wait a year). A
|
|
946
|
+
* cheaper tier the account does not yet fit is listed with what stands in
|
|
947
|
+
* the way ({@link PlanDestination.excess}). The rule's owner is the
|
|
948
|
+
* platform's plan table; a console feeds these rows into its own move
|
|
949
|
+
* model instead of restating it. Additive: absent on responses that
|
|
950
|
+
* predate it, and a client then derives as it did.
|
|
948
951
|
*/
|
|
949
952
|
readonly destinations?: PlanDestination[];
|
|
950
953
|
}
|
|
@@ -956,6 +959,17 @@ interface Account {
|
|
|
956
959
|
interface PlanDestination {
|
|
957
960
|
readonly plan: AccountPlanType;
|
|
958
961
|
readonly intervals: BillingInterval[];
|
|
962
|
+
/**
|
|
963
|
+
* What the account holds beyond what this plan allows: per kind, how many
|
|
964
|
+
* to remove. Present only on a cheaper tier the account does not fit, and
|
|
965
|
+
* then never empty. A move down a tier is booked only by an account that
|
|
966
|
+
* fits it, so the change door refuses the move until the owner has removed
|
|
967
|
+
* the excess, and the field is gone from the next read. A move already
|
|
968
|
+
* booked says the same of itself ({@link ScheduledChange.excess}). Which
|
|
969
|
+
* kinds count is the platform's to decide; a client renders the keys it is
|
|
970
|
+
* given.
|
|
971
|
+
*/
|
|
972
|
+
readonly excess?: Partial<Caps>;
|
|
959
973
|
}
|
|
960
974
|
/**
|
|
961
975
|
* Acknowledgement of `DELETE /account` (202). Termination is asynchronous —
|
|
@@ -2484,6 +2498,10 @@ interface PlansResponse {
|
|
|
2484
2498
|
* consent), and a billed account moving down gets a Stripe Subscription
|
|
2485
2499
|
* Schedule that applies the change at period end. The answer says which
|
|
2486
2500
|
* happened ({@link PlanChangeResponse}).
|
|
2501
|
+
*
|
|
2502
|
+
* A move down a tier is refused while the account holds more than the
|
|
2503
|
+
* destination allows (400, `details.excess` in {@link PlanDestination.excess}'s
|
|
2504
|
+
* shape): it is booked only by an account that fits it.
|
|
2487
2505
|
*/
|
|
2488
2506
|
interface PlanChangeRequest {
|
|
2489
2507
|
readonly plan: AccountPlanType;
|
|
@@ -2505,6 +2523,20 @@ interface ScheduledChange {
|
|
|
2505
2523
|
readonly plan: AccountPlanType;
|
|
2506
2524
|
readonly interval: BillingInterval;
|
|
2507
2525
|
readonly at: number;
|
|
2526
|
+
/**
|
|
2527
|
+
* What the account must remove before `at` to fit the booked plan: per
|
|
2528
|
+
* kind, how many, in {@link PlanDestination.excess}'s shape. A move down a
|
|
2529
|
+
* tier is booked by an account that fits it, so this is absent on the day
|
|
2530
|
+
* of booking and on the change door's answer. The account keeps its
|
|
2531
|
+
* current plan until the change applies, though, and may add a member or
|
|
2532
|
+
* a domain the booked plan has no room for; `GET /account` then counts
|
|
2533
|
+
* them here, for as long as the change is booked, whatever else the
|
|
2534
|
+
* account may or may not order meanwhile. It is a count to REMOVE, not of
|
|
2535
|
+
* what pauses: holdings that do not fit when the change applies are
|
|
2536
|
+
* paused by the platform's own rule, which for members pauses every
|
|
2537
|
+
* member while the account is over. Absent while the account fits.
|
|
2538
|
+
*/
|
|
2539
|
+
readonly excess?: Partial<Caps>;
|
|
2508
2540
|
}
|
|
2509
2541
|
/**
|
|
2510
2542
|
* The answer of `POST /billing/change` — exactly one field is set, and the
|