**What**
- display est. difference in returns as for claims/exchanges
- display order pending difference instead of value computed on FE
---
CLOSES CMRC-949
What
- Remove `fields` from query to export products
Why
- The product export route uses the `fields` in the export request if specified. The `fields` didn't used to be part of the request, but in #11532 we accidentally started using a narrow set of fields as a result of shaving down on the requested data elsewhere in the dashboard.
**What**
- Reworks how admin extensions are loaded from plugins.
- Reworks how extensions are managed internally in the dashboard project.
**Why**
- Previously we loaded extensions from plugins the same way we do for extension found in a users application. This being scanning the source code for possible extensions in `.medusa/server/src/admin`, and including any extensions that were discovered in the final virtual modules.
- This was causing issues with how Vite optimizes dependencies, and would lead to CJS/ESM issues. Not sure of the exact cause of this, but the issue was pinpointed to Vite not being able to register correctly which dependencies to optimize when they were loaded through the virtual module from a plugin in `node_modules`.
**What changed**
- To circumvent the above issue we have changed to a different strategy for loading extensions from plugins. The changes are the following:
- We now build plugins slightly different, if a plugin has admin extensions we now build those to `.medusa/server/src/admin/index.mjs` and `.medusa/server/src/admin/index.js` for a ESM and CJS build.
- When determining how to load extensions from a source we follow these rules:
- If the source has a `medusa-plugin-options.json` or is the root application we determine that it is a `local` extension source, and load extensions as previously through a virtual module.
- If it has neither of the above, but has a `./admin` export in its package.json then we determine that it is a `package` extension, and we update the entry point for the dashboard to import the package and pass its extensions a long to the dashboard manager.
**Changes required by plugin authors**
- The change has no breaking changes, but requires plugin authors to update the `package.json` of their plugins to also include a `./admin` export. It should look like this:
```json
{
"name": "@medusajs/plugin",
"version": "0.0.1",
"description": "A starter for Medusa plugins.",
"author": "Medusa (https://medusajs.com)",
"license": "MIT",
"files": [
".medusa/server"
],
"exports": {
"./package.json": "./package.json",
"./workflows": "./.medusa/server/src/workflows/index.js",
"./.medusa/server/src/modules/*": "./.medusa/server/src/modules/*/index.js",
"./modules/*": "./.medusa/server/src/modules/*/index.js",
"./providers/*": "./.medusa/server/src/providers/*/index.js",
"./*": "./.medusa/server/src/*.js",
"./admin": {
"import": "./.medusa/server/src/admin/index.mjs",
"require": "./.medusa/server/src/admin/index.js",
"default": "./.medusa/server/src/admin/index.js"
}
},
}
```
**What**
- display minutes instead of months
- remove manual offsetting since the server returns ISO format and JS date converts it to local time
---
CLOSES SUP-1069
**What**
- Uses derived state in DataTable, to prevent the state in the URL and component from going out of sync.
- Introduces a way for RouteModals to restore URL params on close.
Resolves CMRC-936
**What**
Currently, the dashboard is fetching way more data than needed to display the products. This can lead to issues for complex catalog. this pr aim to reduce the data to be fetched to exactly what is needed.
<img width="2553" alt="Screenshot 2025-02-19 at 15 08 16" src="https://github.com/user-attachments/assets/b00e856c-e040-4f05-9f15-41fb8d299387" />
**What**
- add `insufficient_inventory` flag when listing shipping options for a cart
- add `enabled_in_store` flag when creating/editing pickup options
**What**
- Fixes an issue where we would parse a string like `"52 tests"` into `52` in the Metadata form
- If a row is deleted we now send off key with an empty string as its value to signify that it should be deleted. This is needed to introduce the API we had for updating metadata in V1. Adrien is implementing the BE support for this.
RESOLVES SUP-895
**What**
- Fixes the wrong `size` being used for the allocate items button.
- Updates the buttons that link to somewhere to use a Link and asChild instead of an onClick.
**What**
- update the create and edit shipping option flows to support pickup (shipping) option
- modify "mark as delivered" for pickup case
---
CLOSES CMRC-906 CMRC-907
**What**
- Add support for defining outlet routes using `@`, e.g. `/src/admin/routes/brands/@create/page.tsx`
- Add support for exporting a `loader` from a route file.
- Add support for exporting a `handle` from a route file.
Example usage of a loader and handle:
```tsx
// src/admin/routes/articles/[id]/page.tsx
import { Button, Container, Heading } from "@medusajs/ui";
import {
Link,
LoaderFunctionArgs,
Outlet,
UIMatch,
useLoaderData,
} from "react-router-dom";
export async function loader({ params }: LoaderFunctionArgs) {
const { id } = params;
return {
id,
};
}
export const handle = {
breadcrumb: (match: UIMatch<{ id: string }>) => {
const { id } = match.params;
return `#${id}`;
},
};
const ProfilePage = () => {
const { id } = useLoaderData() as Awaited<ReturnType<typeof loader>>;
return (
<div>
<Container className="flex justify-between items-center">
<Heading>Article {id}</Heading>
<Button size="small" variant="secondary" asChild>
<Link to="edit">Edit</Link>
</Button>
</Container>
{/* This will be used for the next example of an Outlet route */}
<Outlet />
</div>
);
};
export default ProfilePage;
```
In the above example we are passing data to the route from a loader, and defining a breadcrumb using the handle.
Example of a outlet route:
```tsx
// src/admin/routes/articles/[id]/@edit/page.tsx
import { Button, Container, Heading } from "@medusajs/ui";
const ProfileEditPage = () => {
return (
<div>
{/* Form goes here */}
</div>
);
};
export default ProfileEditPage;
```
This outlet route will be rendered in the <Outlet /> in the above example when the URL is /articles/1/edit
Resolves CMRC-913, CMRC-914, CMRC-915
**What**
In order to prevent multiple version to exists and that might not be compatible with one another, we fix the zod package version in the admin-sdk in complement to the starter
**What**
- Bumps the versions of Vite across the entire stack, to prevent an issue similar to what is described here: https://github.com/vitejs/vite/discussions/18271
Not entirely sure what was happening as I couldn't reproduce the issue, but Adrien faced the issue yesterday when working with local versions of our packages. It does appear as if the range we had before could lead to a version of Vite to be installed with said bug.
