## Summary
**What** — What changes are introduced in this PR?
Export Zod as a dependency of `@medusajs/framework`.
Closes DX-2414
**Why** — Why are these changes relevant or necessary?
Zod is an essential part of Medusa development. We use it in the core and developers use it in their customizations.
Developers using pnpm won't have access to Zod, as it's not a top-level dependency. While they can install any version, since Zod is an essential aspect of our framework, it's more convenient that we export it and make it accessible to developers.
**How** — How have these changes been implemented?
1. Add Zod as a dependency in `@medusajs/deps` and export it in `@medusajs/framework`
2. Change imports of Zod across projects to import from `@medusajs/framework` and remove the Zod dependency.
> Note: this change doesn't cover admin extensions (and our related packages), as they're not related to the Medusa framework and using Zod in them isn't part of the conventions we document.
Developers can import Zod like this now:
```ts
import { z } from "@medusajs/framework/zod"
```
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
Use the following import in a Medusa project to create an validate zod schemas:
```bash
import { MedusaRequest, MedusaResponse } from "@medusajs/framework/http";
import { z } from "@medusajs/framework/zod"
export const PostCustomSchema = z.object({
name: z.string(),
})
type PostCustomSchema = z.infer<typeof PostCustomSchema>
export async function POST(
req: MedusaRequest<PostCustomSchema>,
res: MedusaResponse
) {
res.json({
message: `Hello, ${req.validatedBody.name}`
})
}
// in middleware
import { defineMiddlewares, validateAndTransformBody } from "@medusajs/framework/http"
import { PostCustomSchema } from "./admin/custom/route"
export default defineMiddlewares({
routes: [
{
matcher: "/custom",
middlewares: [validateAndTransformBody(PostCustomSchema)],
},
],
})
```
---
## Examples
-
---
## Checklist
Please ensure the following before requesting a review:
- [x] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [x] I have verified the code works as intended locally
- [x] I have linked the related issue(s) if applicable
---
## Additional Context
-
1. Fix error when passing `--version` and installing Next.js storefront. The error is because the UI package doesn't follow the same versioning as other Medusa packages, so this will skip updating the version of the UI package.
2. Other: added error logging for installation errors
* tests for components (WIP)
* finished adding tests to components
* added tests for providers
* add test command to doc tests
* fix imports
* exclude test files
* remove import
* add vitest as dev dependency
* fix build error
* ignore test files from eslint
* fix test from docs-ui
1. Fix the customer details page crashing when a customer's order is fully refunded. The error was originating from the payment collections of the order not being retrieved, since they're being used to calculate the refunded total.
2. Other: fix country not showing as well due to incorrectly trying to retrieving and access the shipping address's country
Closes#14409
Fix type argument for requests which is necessary for generating OpenAPI specs
## Why
The `StoreVariantListRequest` type used in the `/store/product-variants` route doesn't match the convention of other routes since it doesn't accept a type parameter for the query (or body, but here that's not necessary). This makes it difficult for us to infer the query parameter type of the request.
This change would adapt the `StoreVariantListRequest` to match other conventions in our API routes so that we can generate correct OAS for docs
## Summary
**What** — What changes are introduced in this PR?
- Add HTTP type for update order API route payload + use it in the JS SDK and API route
- other: add `since` tag
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
## Summary
**What** — What changes are introduced in this PR?
- Add missing `images` field of variants to the HTTP types
- Add missing `thumbnail` field to product variant schema, which leads to the thumbnail missing from auto generated types
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.
## Summary
**What** — What changes are introduced in this PR?
Use correct HTTP type parameter for the get claim API route
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
*Please provide answer here*
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## Examples
Provide examples or code snippets that demonstrate how this feature works, or how it can be used in practice.
This helps with documentation and ensures maintainers can quickly understand and verify the change.
```ts
// Example usage
```
---
## Checklist
Please ensure the following before requesting a review:
- [ ] I have added a **changeset** for this PR
- Every non-breaking change should be marked as a **patch**
- To add a changeset, run `yarn changeset` and follow the prompts
- [ ] The changes are covered by relevant **tests**
- [ ] I have verified the code works as intended locally
- [ ] I have linked the related issue(s) if applicable
---
## Additional Context
Add any additional context, related issues, or references that might help the reviewer understand this PR.