Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion dev_deps.ts
Original file line number Diff line number Diff line change
@@ -1,2 +1 @@
export { assertEquals } from "https://deno.land/std@0.196.0/assert/mod.ts";
export * as mf from "https://deno.land/x/mock_fetch@0.3.0/mod.ts";

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed because the mock package is not available anymore

error: Uncaught (in promise) 'Module not found "https://crux.land/router@0.0.5".\n    at https://deno.land/x/mock_fetch@0.3.0/mod.ts:1:46'

12 changes: 10 additions & 2 deletions tests/subscription.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -13,8 +13,11 @@ const subscriptionInput = {
"external_id": "54321",
"billing_time": "calendar",
"subscription_at": "2022-08-08T00:00:00Z",
"purchase_order_number": "PO-123",
},
} satisfies SubscriptionCreateInput;
} satisfies SubscriptionCreateInput & {
subscription: { purchase_order_number: string };
};
Comment on lines +18 to +20

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the & { subscription: { purchase_order_number: string } } needed here? Does it quitely removes the check we want here?

I regenerated the client from the current spec — purchase_order_number?: string | null is already on SubscriptionCreateInput, SubscriptionUpdateInput, SubscriptionObject, WalletCreateInput, WalletUpdateInput, WalletObject, WalletRecurringTransactionRule, WalletTransactionCreateInput and WalletTransactionObject. This compiles with no intersection:

const wt = {
  wallet_transaction: { wallet_id: "1", paid_credits: "100", purchase_order_number: "PO-123" },
} satisfies WalletTransactionCreateInput; // ✅

By widening the target type, the fixture keeps type-checking even if the generated client ever loses the field — which is exactly the regression these fixtures should catch. It also pins the field as required string, where the spec says optional string | null.

Suggest dropping every & { ... } in this PR and going back to plain satisfies X (as const can come back too — it was only dropped because readonly arrays don't satisfy Array<{...}>).


const subscriptionResponse = {
"subscription": {
Expand All @@ -34,8 +37,11 @@ const subscriptionResponse = {
"previous_plan_code": "previous_code",
"next_plan_code": "next_code",
"downgrade_plan_date": "2022-09-14T16:35:31Z",
"purchase_order_number": "PO-123",
},
} satisfies Subscription;
} satisfies Subscription & {
subscription: { purchase_order_number: string };
};

const subscriptionsResponse = {
subscriptions: [subscriptionResponse.subscription],
Expand All @@ -50,6 +56,7 @@ Deno.test("Successfully sent subscription responds with 2xx", async (t) => {
inputParams: [subscriptionInput],
responseObject: subscriptionResponse,
status: 200,
expectedBody: subscriptionInput,
});
});

Expand All @@ -76,6 +83,7 @@ Deno.test(
inputParams: ["id", subscriptionInput],
responseObject: subscriptionResponse,
status: 200,
expectedBody: subscriptionInput,
});
},
);
Expand Down
24 changes: 19 additions & 5 deletions tests/utils.ts
Original file line number Diff line number Diff line change
@@ -1,6 +1,5 @@
// deno-lint-ignore-file no-explicit-any ban-types
import { assertEquals } from "../dev_deps.ts";
import { mf } from "../dev_deps.ts";
import { Client, getLagoError } from "../mod.ts";
import type {
Api,
Expand All @@ -27,10 +26,20 @@ type ExtractLagoResponse<E> = E extends (

const errorMessage = "Lago Error" as const;

export function setupMockClient(route: string, handler: mf.MatchHandler) {
const { fetch, mock } = mf.sandbox();
type MatchHandler = (request: Request) => Response | Promise<Response>;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tests/rate_limit.test.ts:14 already has a local createMockFetch with the comment "replaces broken mock_fetch library". Now there are two hand-rolled mocks in the suite — worth exporting one from here and deleting the other.


mock(route, handler);
export function setupMockClient(route: string, handler: MatchHandler) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

route is typed as plain string here while lagoTest has the precise `${"POST"|"GET"|"PUT"|"DELETE"}@/api/v1/${string}` type on line 64. Worth extracting that into a type LagoRoute and using it in both — right now split("@") will happily hand back path === undefined for a malformed route, and every request then fails on a confusing pathname assertion.

const [method, path] = route.split("@");

const fetch = (async (input: RequestInfo | URL, init?: RequestInit) => {
const request = input instanceof Request ? input : new Request(input, init);
const url = new URL(request.url);

assertEquals(request.method, method);
assertEquals(url.pathname, path);
Comment on lines +38 to +39

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asserting from inside customFetch means failures travel back through the client's error path. In testType: "error" tests they land in the catch on line 103 → getLagoErrorthrow new Error(error), which stringifies the AssertionError and loses the diff output.

Alternative: capture the request in the handler and assert after the client call returns, so mismatches show up as normal assertion failures rather than as request errors.


return await handler(request);
}) as typeof globalThis.fetch;

return Client("api_key", { customFetch: fetch });
}
Expand All @@ -48,6 +57,7 @@ export async function lagoTest<
status,
testType,
urlParams,
expectedBody,
}: {
testType: "error" | "200";
t: Deno.TestContext;
Expand All @@ -59,17 +69,21 @@ export async function lagoTest<
>;
status: number;
urlParams?: Record<string, string>;
expectedBody?: unknown;
},
) {
const client = setupMockClient(
route,
(_req) => {
async (_req) => {
if (urlParams) {
const urlSearchParams = new URLSearchParams(new URL(_req.url).search);
Object.entries(urlParams).forEach(([key, value]) => {
assertEquals(urlSearchParams.get(key), value);
});
}
if (expectedBody) {
assertEquals(await _req.json(), expectedBody);
}
Comment on lines +84 to +86

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if (expectedBody) {
assertEquals(await _req.json(), expectedBody);
}
if (expectedBody !== undefined) {
assertEquals(await _req.json(), expectedBody);
}

Truthiness skips a null / "" / 0 expectation silently. Also, if a test sets expectedBody for a request that carries no body, _req.json() throws a fairly opaque SyntaxError — a request.body guard (or an explicit "expected a body" assertion) would fail more clearly.

return new Response(
responseObject ? JSON.stringify(responseObject) : null,
{ status },
Expand Down
44 changes: 41 additions & 3 deletions tests/wallet.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -15,8 +15,24 @@ const walletInput = {
"granted_credits": 10,
"external_customer_id": "12345",
"expiration_at": "2022-09-14T23:59:59Z",
"purchase_order_number": "PO-123",
"recurring_transaction_rules": [
{
"trigger": "interval",
"interval": "monthly",
"method": "fixed",
"paid_credits": 100,
"granted_credits": 10,
Comment on lines +24 to +25

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here — the create payload types these as string | null in the spec (paid_credits / granted_credits, both top-level and inside recurring_transaction_rules), so this should be "100" / "10".

It doesn't error today only because the WalletInput import on line 3 no longer resolves (the type was renamed to WalletCreateInput), which makes the whole satisfies on line 30 a no-op. Once that import is fixed, this line and the existing rate_amount: 2 / paid_credits: 500 above will all surface.

"purchase_order_number": "PO-RULE-123",
},
],
},
} as const satisfies WalletInput;
} satisfies WalletInput & {
wallet: {
purchase_order_number: string;
recurring_transaction_rules: Array<{ purchase_order_number: string }>;
};
};
Comment on lines +30 to +35

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as the subscription fixture — the intersection isn't needed (WalletCreateInput already has purchase_order_number, including inside recurring_transaction_rules) and it turns the type assertion into something that can't fail.

Worth noting this satisfies is currently inert anyway: WalletInput isn't exported by the generated client anymore (it's WalletCreateInput now; WalletsWalletsPaginated), so TS resolves it to an error type and checks nothing.


const walletResponse = {
"wallet": {
Expand All @@ -35,15 +51,35 @@ const walletResponse = {
"last_balance_sync_at": "2022-09-14T16:35:31Z",
"last_consumed_credit_at": "2022-09-14T16:35:31Z",
"terminated_at": "2022-09-14T16:35:31Z",
"purchase_order_number": "PO-123",
"recurring_transaction_rules": [
{
"lago_id": "483da83c-c007-4fbb-afcd-b00c07c41ffe",
"trigger": "interval",
"interval": "monthly",
"method": "fixed",
"paid_credits": 100,
"granted_credits": 10,
Comment on lines +61 to +62

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

WalletRecurringTransactionRule declares these as strings, so the response fixture needs "100" /
"10":

Suggested change
"paid_credits": 100,
"granted_credits": 10,
"paid_credits": "100",
"granted_credits": "10",

These two lines are also the only new type errors this PR introduces — I ran deno test ./tests against a freshly generated client on both branches: 77 errors on main, 79 here, and the delta is exactly this.

The rule object is also missing fields the response type marks required: status, threshold_credits, grants_target_top_up, started_at, target_ongoing_balance, created_at, expiration_at, invoice_requires_successful_payment, transaction_name, ignore_paid_top_up_limits.

"purchase_order_number": "PO-RULE-123",
},
],
},
} as const satisfies Wallet;
} satisfies Wallet & {
wallet: {
purchase_order_number: string;
recurring_transaction_rules: Array<{ purchase_order_number: string }>;
};
};

const walletUpdateInput = {
"wallet": {
"name": "Wallet name",
"expiration_at": "2022-09-14T23:59:59Z",
"purchase_order_number": "PO-123",
},
} as const satisfies WalletUpdateInput;
} satisfies WalletUpdateInput & {
wallet: { purchase_order_number: string };
};

const walletsResponse = {
wallets: [walletInput.wallet],

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

walletsResponse is built from the input fixture, so it now carries a recurring rule with no lago_id / status and numeric credits — none of which a real list response would return. Using the response fixture instead would keep it honest:

Suggested change
wallets: [walletInput.wallet],
wallets: [walletResponse.wallet],

Expand All @@ -58,6 +94,7 @@ Deno.test("Successfully sent wallet responds with 2xx", async (t) => {
inputParams: [walletInput],
responseObject: walletResponse,
status: 200,
expectedBody: walletInput,
});
});

Expand All @@ -82,6 +119,7 @@ Deno.test("Successfully sent wallet update request responds with 2xx", async (t)
inputParams: ["id", walletUpdateInput],
responseObject: walletResponse,
status: 200,
expectedBody: walletUpdateInput,
});
});

Expand Down
7 changes: 6 additions & 1 deletion tests/wallet_transaction.test.ts
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,11 @@ const walletTransactionInput = {
"wallet_id": "985da83c-c007-4fbb-afcd-b00c07c41ffe",
"paid_credits": 100,
"granted_credits": 10,
"purchase_order_number": "PO-123",
},
} as const satisfies WalletTransactionInput;
} satisfies WalletTransactionInput & {
wallet_transaction: { purchase_order_number: string };
};
Comment on lines +11 to +13

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same intersection point as the other two fixtures — WalletTransactionCreateInput already declares purchase_order_number?: string | null, so plain satisfies covers it and actually fails if the field disappears.

(Heads-up while you're here: WalletTransaction / WalletTransactionInput are stale names too — the generated client exports WalletTransactionCreateInput and WalletTransactionObject now.)


Deno.test(
"Successfully sent wallet transaction responds with 2xx",
Expand All @@ -27,12 +30,14 @@ Deno.test(
transaction_type: "inbound",
amount: 500,
credit_amount: 500,
purchase_order_number: "PO-123",
settled_at: "2022-09-14T16:35:31Z",
created_at: "2022-09-14T16:35:31Z",
},
],
},
status: 200,
expectedBody: walletTransactionInput,
});
},
);
Expand Down
Loading