0462cc5acf
- Change existing data model guides and add new ones for DML - Change module's docs around service factory + remove guides that are now necessary - Hide/remove all mentions of module relationships, or label them as coming soon. - Change all data model creation snippets to use DML - use `property` instead of `field` when referring to a data model's properties. - Fix all snippets in commerce module guides to use new method suffix (no more main model methods) - Rework recipes, removing/hiding a lot of sections as a lot of recipes are incomplete with the current state of DML. ### Other changes - Highlight fixes in some guides - Remove feature flags guide - Fix code block styles when there are no line numbers. ### Upcoming changes in other PRs - Re-generate commerce module references (for the updates in the method names) - Ensure that the data model references are generated correctly for models using DML. - (probably at a very later point) revisit recipes
88 lines
2.4 KiB
Plaintext
88 lines
2.4 KiB
Plaintext
export const metadata = {
|
||
title: `${pageNumber} Feature Flags`,
|
||
}
|
||
|
||
# {metadata.title}
|
||
|
||
In this chapter, you’ll learn about feature flags and how Medusa uses them.
|
||
|
||
## What is a Feature Flag?
|
||
|
||
A feature flag is a configuration that toggles beta features in Medusa.
|
||
|
||
A beta feature may be disabled but is still part of the published `@medusajs/medusa` package. This allows our team to release new features rapidly and continuously without impacting Medusa applications used in production.
|
||
|
||
Developers interested in testing a new feature can enable its flag through Medusa’s configurations.
|
||
|
||
<Note type="warning">
|
||
|
||
Enabling a feature flag isn’t recommended for Medusa applications in a production environment, as it can cause unexpected errors and issues.
|
||
|
||
</Note>
|
||
|
||
{/* TODO re-add this based on whether we have feature flags (after V2). */}
|
||
|
||
{/* ---
|
||
|
||
## List of Feature Flags
|
||
|
||
Refer to this reference for a full list of feature flags. */}
|
||
|
||
---
|
||
|
||
## How to Toggle a Feature Flag
|
||
|
||
### Option 1: Using an Environment Variable
|
||
|
||
A feature flag has an associated environment variable that, if you set it, it toggles the feature flag.
|
||
|
||
For example:
|
||
|
||
```bash
|
||
MEDUSA_FF_TAX_INCLUSIVE_PRICING=true
|
||
```
|
||
|
||
### Option 2: Using Medusa Configurations
|
||
|
||
A feature flag also has an associated key that can be used to toggle its value in Medusa’s configurations.
|
||
|
||
The configurations exported in `medusa-config.js` has a `featureFlags` property. Its value is an object where each key is the key of a feature flag, and its value is a boolean indicating whether to enable or disable the flag.
|
||
|
||
For example:
|
||
|
||
```js title="medusa-config.js"
|
||
module.exports = defineConfig({
|
||
featureFlags: {
|
||
tax_inclusive_pricing: true,
|
||
},
|
||
// ...
|
||
})
|
||
```
|
||
|
||
<Note title="Tip">
|
||
|
||
If you’ve set both the environment variable and the feature flag key in the configurations, the environment variable’s value has a higher precedence.
|
||
|
||
</Note>
|
||
|
||
### Run Migrations
|
||
|
||
A feature guarded by a flag may require changes in the database.
|
||
|
||
So, after enabling a feature flag, it’s recommended to run migrations in your Medusa application:
|
||
|
||
```bash
|
||
npx medusa migrations run
|
||
```
|
||
|
||
If you disable the feature flag, run the following command to revert migrations:
|
||
|
||
```bash
|
||
npx medusa migrations revert
|
||
```
|
||
|
||
<Note>
|
||
|
||
This reverts the last migrations, so if you ran other migrations since you toggled the feature flag, it’ll revert them instead. You can run it multiple times to revert the last migrations.
|
||
|
||
</Note> |