Add support for all checkout creation options #18
Conversation
checkout.go
Outdated
| StoreID string `json:"store_id"` | ||
| VariantID string `json:"variant_id"` | ||
| // Quantities represents variant quantities when creating checkout | ||
| type Quantities struct { |
There was a problem hiding this comment.
Let's use the same structure of variable names so this struct will be
CheckoutCreateDataVariantQuantity instead of Quantities
|
Thanks for the PR @PaulSonOfLars |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #18 +/- ##
==========================================
- Coverage 81.32% 81.18% -0.15%
==========================================
Files 22 22
Lines 573 558 -15
==========================================
- Hits 466 453 -13
+ Misses 55 54 -1
+ Partials 52 51 -1 ☔ View full report in Codecov by Sentry. |
checkouts_service.go
Outdated
| checkoutData["discount_code"] = params.DiscountCode | ||
| } | ||
|
|
||
| func (service *CheckoutsService) Create(ctx context.Context, variantId int, storeId int, attributes *CheckoutCreateAttributes) (*CheckoutApiResponse, *Response, error) { |
There was a problem hiding this comment.
I see you used int for variantId and storeId instead of string I like the idea of int but this will make the library inconsistent, if only one endpoint requires int and the others require string I'll propose either keep as string or refactor all the other endpoints to use int
Another thing is the order of endpoints, usually i use the order of (parent, child, grandchild) so since variant is a property of the storeId it should come after store in the list of parameters.
func (service *CheckoutsService) Create(ctx context.Context, storeID, variantID int, attributes *CheckoutCreateAttributes) (*CheckoutApiResponse, *Response, error) {
}
|
Hi @AchoArnold, thanks for the review! I've gone ahead and made the changes you requested - let me know how those look to you :) |
|
By the way - I noticed your CI isn't running the E2E test; unsure if thats intentional or not. Thought you might want to know if not! |
|
Yep @PaulSonOfLars I usually run the e2e tests locally because It uses an my real account on lemonsqueezy I don't want to corrupt it too much with automated tests. |
This implements the changes mentioned in #16.
Since this required drastically changing the layout of
CheckoutCreateParamsand breaking backwards compatibility, I opted to commit to those breaking changes, and update the signature of the checkout.Create call to reflect the mandatory fields involved.I notice that there are some other types which could use the same changes; namely discounts, subscriptions, and webhooks. Happy to make those changes too if this PR makes it in.