Fixes#13735
### What
This Pull Request introduces new database migrations to remove multiple redundant indexes across several core modules, including product, cart, order, customer, and inventory.
### Why
As detailed in issue #13735, a fresh Medusa installation produces numerous "Duplicate Index" warnings. These legacy indexes add unnecessary write overhead and provide no performance benefit. This PR cleans up the schema to resolve these warnings and improve database health.
### How
I have added one new, reversible migration file for each of the five affected modules:
- `@medusajs/product`
- `@medusajs/cart`
- `@medusajs/order`
- `@medusajs/customer`
- `@medusajs/inventory`
Each migration's `up()` method safely drops the older, redundant index, and its `down()` method re-creates it, ensuring the change is fully reversible and non-destructive.
### Testing
I have tested these migrations by following the local development workflow outlined in the `CONTRIBUTING.md` guide.
1. **Setup:**
* Cloned my forked Medusa repository locally .
* Created a separate, fresh test project using `npx create-medusa-app@latest my-medusa-store`.
* The test project's PostgreSQL database, which already contained the schema with the duplicate indexes.
2. **Linking Local Source Code:**
* In the test project's `package.json`, I modified all `@medusajs/*` dependencies and resolutions to point to the local packages in my forked repository (e.g., `"@medusajs/product": "file:../medusa/packages/modules/product"`).
* From the test project's directory, I ran `yarn install` to link the local, modified Medusa source code into its `node_modules`.
3. **Build & Migration:**
* Inside my forked Medusa repository, I ran `yarn build` to compile the new TypeScript migration files.
* From the root of the **test project**, I then executed the migration command: `npx medusa migration run`.
4. **Verification:**
* The command successfully identified and ran only the new migration files I had created.
* I also confirmed via direct SQL queries that the old, redundant indexes were correctly dropped from all affected tables (`product_collection`, `customer_group`, etc.).
FIXES SUP-1824
**What**
The medusa internal service update should always return the data in the expected shape described by the interface. The medusa service should not have to handle the reshapre
**What**
Apply the `Module` util to each module to handle the export and provide the linkable configuration object.
- Most joiner config that does not have any special config are removed/cleaned up in favor of the autogenerated one or simpler one
- linkable are now available in all modules
- cleaned up the dependencies of the modules
FIXES CORE-2410
**What**
Update the `MedusaService` class, factory and types to remove the concept of main modules. The idea being that all method will be explicitly named and suffixes to represent the object you are trying to manipulate.
This pr also includes various fixes in different modules
Co-authored-by: Stevche Radevski <4820812+sradevski@users.noreply.github.com>
Co-authored-by: Oli Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
- automatically build and consume connection and container loader if not exported by the module
- therefore load the services and repositories automatically, including baseRepository
- automatically build run and revert migrations if not provided
- cleaup modules to remove extra unnecessary bits and pieces
- remove the `initializeFactory` in favor of using `medusaApp`
Should drastically improve the module building DX by removing a lot of boilerplate to handle by the user, that plus the base entity should simplify quite a lot the flow cc @shahednasser
**Note**
I had to choose a way to identify connection and container loader from the exported loader from the module. I decided to go with named function `connectionLoader` and `containerLoader`, also, now the factories will return named function so if the user use the factories we are providing to build those loaders, the function will also be named and identified
