** What
- Allow auto-loaded Medusa files to export a config object.
- Currently supports isDisabled to control loading.
- new instance `FeatureFlag` exported by `@medusajs/framework/utils`
- `feature-flags` is now a supported folder for medusa projects, modules, providers and plugins. They will be loaded and added to `FeatureFlag`
** Why
- Enables conditional loading of routes, migrations, jobs, subscribers, workflows, and other files based on feature flags.
```ts
// /src/feature-flags
import { FlagSettings } from "@medusajs/framework/feature-flags"
const CustomFeatureFlag: FlagSettings = {
key: "custom_feature",
default_val: false,
env_key: "FF_MY_CUSTOM_FEATURE",
description: "Enable xyz",
}
export default CustomFeatureFlag
```
```ts
// /src/modules/my-custom-module/migration/Migration20250822135845.ts
import { FeatureFlag } from "@medusajs/framework/utils"
export class Migration20250822135845 extends Migration {
override async up(){ }
override async down(){ }
}
defineFileConfig({
isDisabled: () => !FeatureFlag.isFeatureEnabled("custom_feature")
})
```
**What**
- Fetches the stock location's details when creating a fulfillment and return fulfillment.
- Passes the data to the fulfillment module, which in turn passes it to the fulfillment provider.
**Why**
- When creating a fulfillment in a multi-location setup the fulfillment provider will need to know where the package is being sent from (so the shipping service can pick it up).
- Previously, we didn't pass anything but the location id to the fulfillment provider. Because the fulfillment provider can't have a dependency on the stock location module this was not sufficient.
- This change ensures there is enough data passed to the fulfillment provider to build integrations properly.
**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>
* feat: initial impl. of Unfulfilled section and create flow
* feat: create fulfillment
* feat: order <> fulfillment link, fulfillment section
* feat: accept order_id when creating fulfillment
* feat: finish create and cancel
* fix: integration test
* refactor: real Order<>Fulfillment link instead readonly, add link step to the workflow
* fix: revert `order_id` definitions
* chore: add changeset
* fix: build
* fix: address comments
* fix: fetch inventory and location levels for fulfilled variant
* fix: loading inventory details
* add isList to order fulfillment link
* fix: duplicate declaration
* fix: type
* refactor: link orders step, fix client
* fix: move translations to the new file
* fix: pass order id in test
---------
Co-authored-by: olivermrbl <oliver@mrbltech.com>
**What**
- Update the `updateShippingOptions` module service API to follow the newest convention
- Add upsert support for shipping options
- update shipping options workflow
- update shipping options api end point and validation
- update shipping options all integration tests
FIXES CORE-1926
**What**
- cleanup existing route on some aspects but not all
- add new create shipping options end point and types
- add set of integration tests
- cleanup existing fulfillment routes
- align existing integration tests
- transform old type to zod types and validators
- fix stock location route
**What**
- Create main workflow
- Update create pricing rule types step to be idempotent
- update remote joiner to support granular isList confguration on field aliases
- Add full workflow integration tests
Before we would swallow the error and return a generic error to the user. This will provide more information to the caller if it is one of the known errors.
what:
- adds fulfillment shipping option rules batch endpoint
- remove fulfillment shipping option rules batch endpoint
- breaks my British based education to not call it fulfilment with a single "l"
**What**
- Update migration for backward compatibility. This does not take into account data migration and table cleanup (@olivermrbl do we have a general tasks for the modules on that subject)?
- Rename fulfillment provider id to provider id
- add integration tests to ensure the migration backward compatibility
- add new module type for the options to be used in the medusa config for example
FIXES CORE-1724
