* feat(index): Add support to trigger sync manually
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* feat(index): Add API route to interact with
* test(): Add http integration tests
* Create weak-elephants-reply.md
## Summary
**What**
Exports the type of medusa's i18n keys from the dashboard package, for autocomplete support.
**Why**
Currently i18next is not able to provide proper ts autocomplete support when adding translations to projects or plugins.
For example when adding a data table or form, I have to go back multiple times to the source i18n files in the medusa repo and search for the exact key name(is it "actions.confirm" or "general.confirm"? etc) and I forget it right after every single time.
Even if all medusa components were provided already translated, it's still very convinient to use keys from medusa(if context appropriate) for some custom components, since they are already translated into many languages(eg "yes", "no" and other very basic strings). Hence why ts support for the base keys would be very helpful
**How**
Modified the generateTypes script to also copy the `en.json` file to the dist folder, and export a `Resources` type with the inferred keys in index.d.ts.
This allows users to define their own i18next type definitions including the base "translation" namespace, example below.
**Testing**
Manual testing
---
## Examples
```ts
// In src/admin/i18next.d.ts
import type enTranslation from "./i18n/en.json" // custom keys
import type { Resources } from "@medusajs/dashboard" // medusa keys
declare module "i18next" {
interface CustomTypeOptions {
fallbackNS: "translation"
resources: {
translation: Resources["translation"]
// all custom namespaces need to merge Resources["translation"] as well
// otherwise when falling back to "translation", strings will have type "never"
myCustomNs: typeof enTranslation & Resources["translation"]
}
}
}
```
Then, both `useTranslation()` and `useTranslation("myCustomNs")` will have proper autocomplete support
---
## 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
- [x] 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
## Summary
**What** — What changes are introduced in this PR?
This PR standardizes heading levels across dashboard components to maintain proper semantic HTML hierarchy.
**Why** — Why are these changes relevant or necessary?
*Please provide answer here*
**How** — How have these changes been implemented?
- Added optional `headingLevel` prop `"h1" | "h2" | "h3"` to `DataTable` component with default value of `"h1"`
- Modified `Heading` component usage to explicitly specify the appropriate level based on context
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
*Please provide answer here*
---
## 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
- [ ] I have linked the related issue(s) if applicable
* Limit the number of ids passed to the different queries to render the tooltip details to 10, for products, product types and shipping options
* Add changeset
* Extract common additional field computation into variable
## Summary
**What** — What changes are introduced in this PR?
This PR is part of a series of PRs to fix HTTP and request type arguments.
This is the last PR in the series. It includes a changeset for the changes made.
**Why** — Why are these changes relevant or necessary?
These types impact the outputted OAS which we show on the API reference. By fixing up the types, we ensure accurate request parameters in the API reference.
**How** — How have these changes been implemented?
Made changes to HTTP types and request type arguments
**Testing** — How have these changes been tested, or how can the reviewer test the feature?
-
---
## Examples
-
---
## 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
-
* virtual i18n module
* changeset
* fallback ns
fallback to the default "translation" ns if the key isnt found. Allows to use a single "useTranslation("customNs")" hook for both custom and medusa-provided keys
* simplify merges
* optional for backward compat
* fix HMR
* fix generated deepMerge
* test
