Release v1.8.0 · medusajs/medusa

Preface

You will find that version 1.8 introduces breaking changes, which might cause you to wonder; why is this not considered a major version?

As we've mentioned in the past, we are currently not following strict semantic versioning. Instead, we use minor versions for breaking changes and patches for all else - and we will continue to do so for the time being.

We apologize in advance for the inconvenience this may cause to your setup.

Introduction

Today, we’re excited to announce the release of Medusa 1.8.

This release comes with many new features while introducing architectural changes contributing toward making Medusa more modular and portable to new, modern environments.

We’ve added multi-warehouse capabilities and support for nested categories, introduced a new payment processor interface (and migrated the most used plugins Stripe and Paypal), moved Medusa Admin to our mono-repository, and revamped it to be shipped as an npm package (like all other packages), expanded our OpenAPI Spec tooling and added dedicated types packages for client applications, upgraded Typeorm, and created a range of new modules leveraging our Modules API.

The overall theme of this release has been modularity. All changes introduced in 1.8 are dedicated to making Medusa a toolbox for developers to create rich commerce applications. We are enabling a future for commerce businesses where they can focus on innovation and differentiating – without having to worry about re-platforming or hacky workarounds.

Our packages are all open-source, free, and extensible.

Get Started

It's recommended to use yarn when updating the following dependency to avoid any unexpected errors.

To get started using Medusa 1.8, you can create a new project using our Quickstart guide or follow the steps outlined below:

First, upgrade your version of Typeorm:

yarn add [email protected]

The dependency on Typeorm has been upgraded from 0.2.31 to 0.3.11, that comes with significant breaking changes. Follow Typeorm's upgrade guide to refactor your custom code.

Install the 1.8 version of the core:

yarn add @medusajs/medusa@latest

The core engine doesn't come with a Redis caching mechanism and Redis events system any longer. Instead, the core relies on the Module API for those two sub-systems.

As a result, you must install and use those modules to ensure your application works as expected.

Install the new Redis cache module with the following command:

yarn add @medusajs/cache-redis@latest

Install the new Redis event bus module with the following command:

yarn add @medusajs/event-bus-redis@latest

Then, add both modules to the exported configuration in medusa-config.js:

module.exports = {
  // ...
  modules: {
    eventBus: {
      resolve: "@medusajs/event-bus-redis",
      options: {
        redisUrl: "your-redis-url"
      }
    },
    cacheService: {
      resolve: "@medusajs/cache-redis",
      options: {
        redisUrl: "your-redis-url"
      }
    }
  }
}

Replace your-redis-url with the URL to your Redis instance.

Finally, run migrations to ensure your database is up to date with our schema changes:

medusa migrations run

You are now set up to start using 1.8.

There are plenty of other features and improvements to leverage in your project. Those are covered in the following sections.

But before that, here’s a non-exhaustive overview of what’s new in Medusa 1.8:

Multi-warehouse
Nested Categories
Medusa Admin plugin
Payment Processors
Event Bus module
Cache module
Inventory module
Stock Location module
OAS Tooling and client types packages
Types and Utils packages
Search plugins update
Performance improvements
Typeorm update

What’s new in 1.8?

Feature flags

You'll find the following feature flags in 1.8:

Name	Flag	Description	Default value
Order Editing	`order_editing`	Allows you to edit Orders after having been placed	`true`
Product Categories	`product_categories`	Organize your products to provide customers with a better browsing experience as they navigate your catalog.	`false`
Sales Channels	`sales_channels`	Group your products in and receive Orders from different channels	`true`
Tax-inclusive Pricing	`tax_inclusive_pricing`	Specify prices with tax included	`false`

Modules

The terms modules and Modules API are used extensively throughout these release notes, so we want to preface the features overview with a short explanation of the concept. Refer to the product announcement and our documentation for more elaborate walkthroughs.

As mentioned, the overall theme of this release has been modularity. We have started breaking up our monolithic core into modules. These modules are isolated bundles of code encapsulating a specific domain. Domain in this context refers to an area in your application that is logically coherent e.g. users, products, cart, etc.

The modules separate the concerns in Medusa at an architectural level and pave the way for more extensibility and customizability of your setup. Furthermore, the modules live separately from the core, allowing developers to run them independently from the main application.

As such, applying these architectural changes across all domains will make almost any part of Medusa entirely replaceable and capable of running on infrastructure in isolation from each other e.g. in a serverless environment, on edge, etc.

In 1.8, the usage of our Modules API is rather simple. We are introducing four modules; events, caching, inventory, and stock location. Initially, these modules live up to one of the two characteristics mentioned. They are entirely replaceable.

A module comes with a definition containing information about its configuration and capabilities. These definitions can be found in the new Modules SDK package, @medusajs/modules-sdk, in the file definitions.ts.

Let's take the event bus module definition as an example to describe the properties:

{
    key: "eventBus",
    registrationName: "eventBusModuleService",
    defaultPackage: "@medusajs/event-bus-local",
    label: "EventBusModuleService",
    canOverride: true,
    isRequired: true,
    defaultModuleDeclaration: {
      scope: MODULE_SCOPE.INTERNAL,
      resources: MODULE_RESOURCE_TYPE.SHARED,
    },
  },

Property	Description
key	The key to register a module in your `medusa-config.js`. As you did with the event bus module in the Get Started section above.
registrationName	The name of the main service of the module and its registration in the Awilix dependency container.
defaultPackage	If the module comes with a default package, it will be added directly in the definition. If there's no default package, this value is `false`.
label	Readable label to identify the module
canOverride	If `true`, the module is replaceable
isRequired	If `true`, the module is required
defaultModuleDeclaration.scope	The module can be internal or external. An internal module communicates with other services part of the same application. An external module communicates with other services via a separate protocol e.g. HTTP, rpc, etc.
defaultModuleDeclaration.resources	The module can share resources with the core. A module that shares resources with the core uses the same database connection in the core. A module that does not share resources with the core establishes a separate connection or uses a different data store.

Modules are loaded similarly to plugins. Upon server start, we look for modules in your medusa-config.js and register them, given they are correctly configured.

In medusa-config.js, modules are registered as shown previously:

module.exports = {
  projectConfig,
  plugins,
  modules: {
    eventBus: {
      resolve: "@medusajs/event-bus-redis",
      options: {
        redisUrl: "your-redis-url"
      }
    }
  }
}

In the example above, we override the default event bus module with a Redis implementation. The resolve property of the module configuration can point to a package on npm or a local folder/file. The options are injected into the module upon initializing it. You can find more on this in our documentation.

What's to come

We are actively working toward making modules capable of booting up outside of the core in complete isolation hereby living up to the second of the two characteristics.

To give you an idea of what we are building, consider the following handler:

import { initialize } from "@medusajs/cart"
import { NextApiRequest, NextApiResponse } from "next"

const cartService = await initialize()

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const { cart_id } = req.query
  const { quantity, variant_id } = req.body

  try {
    const cart = await cartService.addLineItem(cart_id, { quantity, variant_id })

    res.json({ cart })
  } catch (e) {
    res.status(400).json({ error: e.message })
  }
}

Now, please don't get caught up in the details. The above code snippet is not necessarily exactly what it will look like but merely an example to communicate the road ahead for modules.

This way of working with modules is exceptionally flexible. It equips developers with a powerful toolkit to build commerce applications similar to how you build other applications in your stack. For example, using Medusa in concert with a framework like Next.js will allow developers to build a full-stack application within a single project.

We are excited to share more on this as our development advances.

Now that we are familiar with the fundamentals of modules let's proceed with the new features in 1.8.

Multi-warehouse

Expand into multiple warehouse locations with our new Inventory and Stock Location modules.

Installation
The multi-warehouse features will be enabled by installing and configuring the two modules:

yarn add @medusajs/inventory@latest @medusajs/stock-location@latest

module.exports = {
  projectConfig: {
    database_url: DATABASE_URL,
    ...
  },
  plugins,
  modules: {
    inventoryService: "@medusajs/inventory",
    stockLocationService: "@medusajs/stock-location",
  },
}

Run migrations:

medusa migrations run

And finally, run a script to migrate current product variant information to fit the schema changes introduced by these modules:

node ./node_modules/@medusajs/medusa/dist/scripts/migrate-inventory-items.js

After setting up the modules, a new set of settings in Medusa Admin will be available.

Managing inventory
In the Inventory section, you'll obtain a comprehensive overview of your inventory items within a specific warehouse, providing you with a clear understanding of your real-time stock.

Managing inventory items
Inventory is managed together with an inventory item’s variant information.

Flexible fulfillment
Fulfill orders from various locations, including the ability to split orders across stock locations.

Read the full product announcement here.

Nested Categories

Our new Product Category API allows you to create, nest, and rank categories and add products to each. Categories are a way to organize your products to provide customers with a better browsing experience as they navigate their way through your catalog.

The feature is released under a feature flag. You can enable it by adding the following to your project configuration in medusa-config.js:

module.exports = {
  projectConfig: {
    database_url: DATABASE_URL,
    ...
  },
  plugins,
  modules,
    featureFlags: {
      product_categories: true
    }
};

And run migrations (these might already be applied to your database, as we have only hidden the API behind the flag):

medusa migrations run

You now have a simple yet powerful Product Category API at your fingertips. Combine the API with other features of Medusa to create a fantastic customer experience and manage it all in your admin, as seen below:

Read the full product announcement here or dive into the technical details of the feature in the RFC.

Medusa Admin as a plugin

Moving Medusa Admin to the core has been a long-standing wish of ours, and we are very excited to finally see it happen. The move was motivated by frequent issues with versioning between core and admin features and an eagerness to improve the developer experience - internally and externally.

The new Medusa Admin is released as @medusajs/admin and can be installed directly into your Medusa project – similar to any other plugin.

There are two ways of using the new admin plugin; serve it on the server or use its build tooling to deploy it on a hosting platform e.g. Vercel or Netlify.

The following steps demonstrate how to start using the admin plugin on the server. Install it with the following command:

yarn add @medusajs/admin@latest

Add it to your plugins in medusa-config.js:

module.exports = {
  projectConfig,
  modules,
  featureFlags,
  plugins: [
    ...
      {
        resolve: "@medusajs/admin",
        /** @type {import('@medusajs/admin').PluginOptions} */
        options: {
          autoRebuild: true,
        },
      },
    ]
};

Add and run the build script:

// package.json

...
"scripts": {
  ...
  "build:admin": "medusa-admin build"
}
...

yarn build:admin

Upon starting the server after these steps, Medusa Admin will live on the path /app on your server URL.

We highly recommend reading through the full product announcement and the technical overview, as it is important to understand the limitations and features of the admin plugin.

Event bus module

The framework powering the events system of Medusa will no longer be baked into the core package. In 1.8, we are introducing an event bus module alongside two implementations; one using the Node EventEmitter, and the other using Redis.

The event bus module lets businesses choose the underlying technology powering their events system. Medusa has always relied on Redis and Bull for handling events. But as businesses increasingly adopt Medusa into their existing technology stack, we’ve seen a rise in demand for leveraging existing infrastructure. Businesses that already have an events system in place can now configure Medusa to leverage that instead of having to spin up additional services, adding unnecessary complexity to their stack.

By default, Medusa will come with the Node EventEmitter event bus installed. We advise using the Redis event bus for projects already in or close to production, as it is geared toward production environments.

To install the Redis event bus, you first install the new package:

yarn add @medusajs/event-bus-redis@latest

The new events system is leveraging our Module API, so you must configure it in your project configuration in medusa-config.js:

module.exports = {
  projectConfig,
  plugins,
  featureFlags,
  modules: {
    eventBus: {
      resolve: "@medusajs/event-bus-redis",
      options: {
        redisUrl: "your-redis-url"
      }
    }
  }
}

After configuring the Redis event bus module, you can start your server as if nothing has changed.

Read the full product announcement here, and refer to the module README for an overview of the options you can pass to the event bus.

Cache module

The framework powering the caching mechanism of Medusa will neither no longer be baked into the core package. In 1.8, we are introducing a cache module alongside two implementations, one storing data in memory and the other using Redis.

The motivation behind adding the cache module is the same as with the event bus. It is a step toward a more flexible architecture where businesses are not constrained to a specific piece of technology.

By default, Medusa will come with the in-memory cache module installed. Though again, we advise using the Redis module for production environments, as the in-memory one does not scale well.

To use the Redis cache module, you first install the new package:

yarn add @medusajs/cache-redis@latest

Configure it in your project configuration in medusa-config.js:

module.exports = {
  projectConfig,
  plugins,
  featureFlags,
  modules: {
    cacheService: {
      resolve: "@medusajs/cache-redis",
      options: {
        redisUrl: "your-redis-url"
      }
    }
  }
}

After configuring the cache module, you should be able to start your server as if nothing has changed.

Read the full product announcement here.

Payment Processor API

This release thoroughly cleans up our payment plugin domain and introduces a fresh new interface for building integrations with payment providers; the Payment Processor API.

export interface PaymentProcessor {
  /**
   * Return a unique identifier to retrieve the payment plugin provider
   */
  getIdentifier(): string

  /**
   * Initiate a payment session with the external provider
   */
  initiatePayment(
    context: PaymentProcessorContext
  ): Promise<PaymentProcessorError | PaymentProcessorSessionResponse>

  /**
   * Update an existing payment session
   * @param context
   */
  updatePayment(
    context: PaymentProcessorContext
  ): Promise<PaymentProcessorError | PaymentProcessorSessionResponse | void>

  /**
   * Refund an existing session
   * @param paymentSessionData
   * @param refundAmount
   */
  refundPayment(
    paymentSessionData: Record<string, unknown>,
    refundAmount: number
  ): Promise<
    PaymentProcessorError | PaymentProcessorSessionResponse["session_data"]
  >

  /**
   * Authorize an existing session if it is not already authorized
   * @param paymentSessionData
   * @param context
   */
  authorizePayment(
    paymentSessionData: Record<string, unknown>,
    context: Record<string, unknown>
  ): Promise<
    | PaymentProcessorError
    | {
        status: PaymentSessionStatus
        data: PaymentProcessorSessionResponse["session_data"]
      }
  >

  /**
   * Capture an existing session
   * @param paymentSessionData
   */
  capturePayment(
    paymentSessionData: Record<string, unknown>
  ): Promise<
    PaymentProcessorError | PaymentProcessorSessionResponse["session_data"]
  >

  /**
   * Delete an existing session
   */
  deletePayment(
    paymentSessionData: Record<string, unknown>
  ): Promise<
    PaymentProcessorError | PaymentProcessorSessionResponse["session_data"]
  >

  /**
   * Retrieve an existing session
   */
  retrievePayment(
    paymentSessionData: Record<string, unknown>
  ): Promise<
    PaymentProcessorError | PaymentProcessorSessionResponse["session_data"]
  >

  /**
   * Cancel an existing session
   */
  cancelPayment(
    paymentSessionData: Record<string, unknown>
  ): Promise<
    PaymentProcessorError | PaymentProcessorSessionResponse["session_data"]
  >

  /**
   * Return the status of the session
   */
  getPaymentStatus(
    paymentSessionData: Record<string, unknown>
  ): Promise<PaymentSessionStatus>
}

Our Stripe and PayPal payment plugins have been migrated to follow this interface.

We’ve removed all database mutations from the plugins to constrain their functionality to only be about communicating with the 3rd party service. This will mitigate the risk of nasty issues with database transactions spanning the core and plugins.

To mutate entities in the core database from a payment plugin, you must pass an update request in your call to initiate the payment. This flow may sound complex, but it is fairly straightforward, as seen in the example below.

The core payment provider service initiates payments. To create a payment object specific to your provider, we call the plugin method initiatePayment. The plugin must respond with a PaymentSessionResponse that has the following shape:

export type PaymentSessionResponse = {
  update_requests: { customer_metadata: Record<string, unknown> }
  session_data: Record<string, unknown>
}

As you might have guessed, the update_requests property is what you will be using to mutate data in the core. In the first iteration, we define the constraints of the update requests, which are initially limited to customer metadata.

In the case of Stripe, we store the Stripe customer id on the customer entity in Medusa, such that we can identify customers and potentially present payment methods on subsequent orders.

So from the initiatePayment method in the Stripe plugin, we “send back” the following object to the core:

{
  session_data,
  update_requests: customer?.metadata?.stripe_id
    ? undefined
    : {
        customer_metadata: {
          stripe_id: intentRequest.customer,
        },
      },
}

This will trigger the payment provider service in the core to update the Medusa customer metadata with the Stripe customer id.

We’ve added backward compatibility in the Stripe and PayPal plugins, as these are by far the most used providers. That said, we highly recommend updating the core and plugins to the latest versions as soon as possible to avoid any unexpected issues.

Read the full product announcement here.

OAS tooling and improvements

We will introduce the first iteration of our OpenAPI Spec (OAS) tooling, including automated SDK generation, a thorough clean-up of our OAS in the API layer, and a new types package.

Included in the OAS tooling, we ship a CLI allowing you to extend our SDKs and types based on custom OAS in your Medusa project.

Let's say you have the following OAS schema in your own project in file src/simple-product.ts:

/**
 * @schema SimpleProduct
 * title: "SimpleProduct"
 * description: "Pretty simple product"
 * type: object
 * required:
 *   - handle
 *   - id
 * properties:
 *   id:
 *     description: The product's ID
 *     type: string
 *     example: prod_01G1G5V2MBA328390B5AXJ610F
 *   handle:
 *     description: A unique identifier for the Product (e.g. for slug structure).
 *     nullable: true
 *     type: string
 *     example: coffee-mug
 */

You can extend our Store API OAS output with this schema by running the following command (given that you have the CLI installed):

yarn medusa-oas-cli oas --type store --paths ~path-to-your-project/src

This will add the SimpleProduct to the generated store.oas.json:

"SimpleProduct": {
  "title": "SimpleProduct",
  "description": "Pretty simple product",
  "type": "object",
  "required": [
    "handle",
    "id"
  ],
  "properties": {
    "id": {
      "description": "The product's ID",
      "type": "string",
      "example": "prod_01G1G5V2MBA328390B5AXJ610F"
    },
    "handle": {
      "description": "A unique identifier for the Product (e.g. for slug structure).",
      "nullable": true,
      "type": "string",
      "example": "coffee-mug"
    }
  }
}

Now that you've generated your OAS, you can create a type to live alongside all the types from our core. You do so by running the following command:

yarn medusa-oas client --src-file ./store.oas.json --out-dir ./src/client-types --type store --component types

Inspect the ./src/client-types and find your SimpleProduct.ts in the models/ folder.

With great excitement, we also announce the @medusajs/client-types package - a highly requested package that separates client types from the core. It has been reported several times that importing the core package in client applications to use types is far from ideal. It blows up the bundle size of the application and introduces many unnecessary dependencies. You should now be able to remove the dependency on the core package and use the client types one instead.

Read the full product announcement here.

Types and Utils packages

In the same vein, we are also introducing two new packages for utils and types that live without a dependency on the core.

The reasoning is the same as with the client types; we want to improve the developer experience when building server applications by eliminating the need to import a huge core package to leverage our types.

Initially, these packages will contain very few types, but we will move all common, shared types and utils to the two new packages in the coming months.

The packages are published under:

@medusajs/types
@medusajs/utils

Search plugins update

We are extending the capabilities of search services and updating all plugins to use the latest version of their provider-specific SDK.

We are now exposing a transformer function in the config, allowing developers to build custom resource transformers. Effectively, this means you’ll be able to store the entities of Medusa in whatever format fits your use case.

As always, search plugins are configured in medusa-config.js. You can add the transformer function on a per-index basis. The following example is for a products index:

 {
    resolve: "medusa-plugin-meilisearch",
    options: { 
      apiKey: "api-key", 
      host: "http://localhost:7700" },
      products: {
        indexSettings: {
	  searchableAttributes: ["title", "description", "variant_sku"],
	  displayedAttributes: ["title", "description"],
        },
        transformer: (product: Product) => {
	  return {
            id: product.id,
            title: `Custom title: ${product.title}`,
	  }
        }
      }
  }

The attentive reader might have spotted that we are now nested provider-specific settings in a variable indexSettings. This has been added to allow for the transformer feature. The settings are backward compatible, but if you want to leverage the transformer, you must fit the new shape of the configuration.

Performance improvements

Aside from modularity, we have another central focus area: performance improvements. We are pushing hard to ensure that all frequently used domains such as Orders, Products, and Checkout are remarkably performant.

We are currently synthesizing benchmarks to share publicly. Until these are published, you can refer to the following pull requests to see the changes and related tests:

Upgrade to Typeorm v0.3.11

We’ve upgraded Typeorm from 0.2.31 to ^0.3.11 to leverage a range of significant improvements added by the Typeorm team in 0.3.

This upgrade has brought with it a large amount of breaking changes. Refer to their release notes for an overview of all breaking changes.

We will only cover the changes that affected Medusa, and how you should handle them in your custom implementations.

Changes to find and findOne

You can find a detailed walkthrough of the changes to these methods in Typeorm’s release notes. We’ll cover it briefly.

find() without any arguments used to return all records of a given entity. This now throws an error. You have to pass an empty object to achieve the same behaviour as before.
findOne({}) and findOne(undefined) used to return the first record of a given entity. These now return null.
findOne(id) has been dropped. To retrieve an entity by id, you now have to use findOneBy({ id: "some_id" })
findOne() now requires a where option in its query object to filter data findOne({ where: { ... }}). The same goes for methods findOne, findOneOrFail, find, count, findAndCount.
Querying for enums now requires you to use the enum value directly. You cannot pass the string value of the enum.

Utilities

We’ve added utilities that transform data from what was previously expected to the new format to make the upgrade seamless. You can find those in the build-query.ts utility file.

Repositories

Repositories no longer extend a base class, nor are they of type class. They are created as extensions to the DataSource.

DataSource

Typeorm’s Connection has been deprecated in favor of DataSource.

Other noteworthy changes

Minimum Node.js version bumped from 14 to 16. Version 14 will reach end-of-life on April 30.
Gift Card page in Medusa Admin changed to use the same components as the Product page
Sign in page in Medusa Admin simplified
Remove Gatsby + Admin from npx create-medusa-app command
Graceful shutdown of the server
Removed Publishable API Keys feature flag

What’s next?

As mentioned, we are pushing the modularity agenda hard these days. In the near future, you’ll see other domains of Medusa shipped as modules and support for spinning these up in complete isolation.

You can find our tentative roadmap on GitHub Discussions. This is forever work-in-progress, and we will continuously update and refine it to fit the needs of our users and the general developer community.

Give Medusa 1.8 a go - we are excited to hear your thoughts. As always, please report GitHub Issues in our repository, and file feature requests on GitHub Discussions.

Happy hacking!

Team Medusa 💜

A huge thanks to all contributors to this release - you've all been absolutely killing it to make this release a reality!

Features

feat(medusa-plugin-algolia): Revamp Algolia search plugin (#3510)
feat(admin-ui): Encode location id in URL on location table (#3533)
feat(medusa): Modules initializer (#3352)
feat(admin): Improve DX for deploying admin externally (#3418)
feat(admin-ui): Implements redesign of public pages (#3504)
feat(medusa): seed command can create product categories (#3528)
feat(admin, medusa): add locations to claim and swap creation (#3522)
feat(medusa): Add event emitter to ProductCollectionService (#3495)
feat(codegen): commit generated client types to codebase (#3492)
feat(medusa-plugin-meilisearch): Update + improve Meilisearch plugin (#3377)
feat(admin-ui): Add location names to fulfilment rows and timeline events (#3481)
feat(medusa): handle reservation quantity update for line items (#3484)
feat(oas): declare x-expanded-relations - Admin (#3483)
feat(oas): declare x-expanded-relations - Store (#3482)
feat(modules-sdk,inventory,stock-location): modules isolated connection (#3329)
feat(codegen,types): SetRelation on expanded types (#3477)
feat(medusa, admin-ui, medusa-react, medusa-js): Allow toggling of manage inventory (#3435)
feat(admin-ui, medusa): request return with location (#3451)
feat(medusa, admin-ui): increase tree depth + scope categories on store + allow categories relation in products API (#3450)
feat(codegen): x-expanded-relations (#3442)
feat(types): package scaffolding for generated types (#3452)
feat(medusa): Cache modules (#3187)
feat(medusa,medusa-core-utils): graceful shutdown server (#3408)
feat(medusa, medusa-js, medusa-react): Add store queries to react medusa (#3436)
feat(oas-cli): combine admin + store + custom OAS (#3411)
feat(admin-ui): added breadcrumbs for categories on create/edit modal (#3420)
feat(oas): add @Schema OAS for address request payloads (#3423)
feat(medusa, admin-ui): Improvements to product categories (#3416)
feat(admin-ui, medusa-js, medusa-react, medusa): Multiwarehousing UI (#3403)
feat(admin-ui, medusa-react): product page categories management + nested multiselect (#3401)
feat(medusa): category list API can return all descendants (#3392)
feat(admin-ui): adds category ui for tree/list, edit, create, delete (#3399)
feat(admin-ui): ProductCategory list page (#3380)
feat(medusa): categories can be ranked based on position (#3341)
feat(admin,admin-ui,medusa): Add Medusa Admin plugin (#3334)
feat(medusa): Performance improvement of DraftOrder creation (#3350)
feat(medusa): Add Lifetime support on project/plugin services (#3349)
feat(medusa-payment-stripe): Stripe PaymentProcessor implementation (#3257)
feat(medusa, stock-location): Sales channel filtering when listing locations (#3324)
feat(medusa) allow querying category descendants with a param in list endpoint (#3321)
feat(medusa,modules-sdk): Modules SDK package (#3294)
feat(oas): pluralize OAS tags (#3315)
feat(oas): include /admin and /store in paths URLs (#3314)
feat(medusa-file-s3): S3 file service reusing a single AWS client (#3260)
feat(oas): identify required fields in responses - store (#3282)
feat(oas): identify required fields in responses - admin (#3278)
feat(docs): OAS circular reference check shall fail openapi:generate (#3269)
feat(medusa): Expose an activeManager_ getter in TransactionBaseService (#3256)
feat(medusa-react): add product category queries and mutations (#3218)
feat(medusa-js, medusa-react, medusa): Prepare API for admin implementations (#3110)
feat(oas): medusa-oas-cli as OAS build tool (#3213)
feat(admin-ui, medusa-react): product page categories management + nested multiselect (#3401)
feat(medusa): category list API can return all descendant (#3392)
feat(codegen): openapi-typescript-codegen fork (#3272)
feat(medusa): Typeorm upgrade to 0.3.11 (#3041)
feat(admin-ui): Request return flow warnings and errors (#3473) @pKorsholm
feat(oas-cli): output better error when no command is provided (#3559) @patrick-medusajs
feat(admin-ui, medusa): Improve fulfillment validation (#3541) @pKorsholm
feat(medusa): invalidate price selection caching within update request (#3553) @fPolic
feat(medusa): Categories - Adds indexes + remove soft delete (#3589) @riqwan
feat(medusa-payment-paypal): Migrate to the new payment processor API (#3414) @adrien2p
feat(admin-ui): move inventory item fields into manage inventory modal (#3591) @pKorsholm
feat(medusa): remove created reservations on subsequent failure for cart completion (#3554) @pKorsholm
feat(medusa): Remove reservations for all line items when an order edit is accepted (#3544) @pKorsholm
feat(admin-ui): Make number input increment/decrement buttons not tabbable-to (#3645) @StephixOne
feat(admin-ui, medusa): admin UI metadata (#3644) @kasperkristensen
feat(admin-ui): Add new feature badge for categories and inventory (#3657) @StephixOne

Bugs

fix(admin-ui): show failure reason for batch jobs (#3526)
fix(medusa): fix bug with parent not being saved correctly (#3534)
fix(admin-ui): Try and ensure allocation table checkmarks align better (#3535)
fix(admin-ui): Fix location address editing form state (#3525)
fix(medusa, admin-ui): Fix edit order variant stock (#3512)
fix(admin-ui): Hide create fulfilment button when nothing left to fulfil (#3515)
fix(admin): draft order shipping details (#3500)
fix(medusa): Error messages for reset tokens (#3514)
fix(medusa): Use get for creating fulfillments (#3498)
fix(medusa): fix rank order changing on category update (#3486)
fix(medusa-react): invalidate products query on category delete (#3485)
fix(admin-ui): Fix inventory table pagination on location filter change (#3479)
fix(oas,js,react): use AdminExtendedStoresRes instead of AdminStoresRes (#3478)
fix(inventory, stock-location): Remove orphaned location levels and reservations (#3460)
fix(medusa): Missing location id on fulfillments (#3462)
fix(admin-ui): hide categories in products behind feature flag (#3467)
fix(admin-ui): Inventory and order UI fixes and tweaks (#3461)
fix(admin-ui): Edit allocation update (#3447)
fix(admin-ui): Lint all UI files (#3459)
fix(oas): fix OAS typos in AdminVariant (#3453)
fix(admin-ui): Show all locations in allocation creation modal (#3448)
fix(admin): Fix fulfilment creation (#3434)
fix(admin-ui): border overflow (#3437)
fix(admin): Show correct reserved/available values when editing stock on variant (#3438)
fix(medusa, admin-ui): Order allocations (#3419)
fix/disable allocate button (#3426)
fix(admin,oas-github-cli): Make staging release pipeline pass (#3410)
fix(medusa): Issue when ordering with multiple columns (#3385)
fix(admin-ui): Fix use of expand parameter on order page (#3383)
fix(admin-ui): move dependencies from devDependencies (#3405)
fix(admin-ui): table action gap (#3386)
fix(admin-ui): Resolve tailwindcss/nesting correctly (#3404)
fix(medeusa): Transform query includes options should only be added to allowed props if there is already at least one allowed props (#3362)
fix(admin-ui, medusa): stock location fixes (#3395)
fix(ci,oas) move oas ci script to a package under the oas workspace (#3391)
fix(admin-ui): Discount in DraftOrder create flow (#3378)
fix(admin): Add skus to claim menus (#3368)
fix(medusa-payment-stripe): Add typescript to dev deps (#3371)
fix(medusa): Plugin repository loader (#3345)
fix(medusa): Update typescript types to reflect oas and return types (#3344)
fix(medusa): Account for multiple inventory items in get-inventory (#3094)
fix(medusa): update create fulfillment flow (#3172)
fix(medusa): Clean response data usage for admin and store fields/expand (#3323)
fix(medusa): Reservation routes and VariantInventory type (#3328)
fix(medusa): Only add ordering select if not already present (#3319)
fix(oas): add missing x-codegen + fix schema naming and $ref (#3312)
fix(medusa): fixes bug for mpath incorrectly updated for nested categories (#3311)
fix(medusa-dev): include packages/ subdirectories in discovery (#3293)
fix(oas): fix paths and fix schema names to match convention (#3288)
fix(admin-ui): Fix use of expand parameter on order page (#3383)
fix(admin-ui): move dependencies from devDependencies (#3405)
fix(admin-ui): table action gap (#3386)
fix(admin-ui): Resolve tailwindcss/nesting correctly (#3404)
fix(medeusa): Transform query includes options should only be added to allowed props if there is already at least one allowed props (#3362)
fix(admin-ui, medusa): stock location fixes (#3395)
fix(ci,oas) move oas ci script to a package under the oas workspace (#3391)
fix(admin-ui): Discount in DraftOrder create flow (#3378)
fix(admin): Add skus to claim menus (#3368)
fix(medusa-payment-stripe): Add typescript to dev deps (#3371)
fix(medusa): Plugin repository loader (#3345)
fix(medusa): Update typescript types to reflect oas and return types (#3344)
fix(medusa): Account for multiple inventory items in get-inventory (#3094)
fix(medusa): update create fulfillment flow (#3172)
fix(medusa): Clean response data usage for admin and store fields/expand (#3323)
fix(medusa): Reservation routes and VariantInventory type (#3328)
fix(medusa): Only add ordering select if not already present (#3319)
fix(oas): add missing x-codegen + fix schema naming and $ref (#3312)
fix(medusa): fixes bug for mpath incorrectly updated for nested categories (#3311)
fix(medusa-dev): include packages/ subdirectories in discovery (#3293)
fix(oas): fix paths and fix schema names to match convention (#3288)
fix(event-bus-local): Error handling (#3575) @adrien2p
fix(admin-ui): multi warehouse minor fixes (#3540) @pKorsholm
fix(admin): OrderEdit display of difference due with refund (#3487) @fPolic
fix(admin-ui): Fix effect check in inventory table and overflow UI (#3577) @StephixOne
fix(admin-ui): Hide inventory quantity field in variant stock form if SL module enabled (#3592) @StephixOne
fix(medusa-file-s3): Update key formation to use timestamp (#3601) @IgorKhomenko
fix(medusa): Include inventory quantity when listing products (#3586) @pKorsholm
fix(admin-ui): disallow creating OE if there is no changes (#3604) @fPolic
fix(admin-ui): Create fulfillment (#3607) @pKorsholm
fix(admin-ui): Update order edit variants table to fit longer content (#3608) @StephixOne
fix(modules-sdk): check if dependency is registered (#3620) @carlos-r-l-rodrigues
fix(medusa-cli): add semver dependency (#3603) @kasperkristensen
fix(medusa, admin-ui): List all inventory levels (#3552) @pKorsholm
fix(admin-ui): delete inventory item when variant is deleted (#3585) @pKorsholm
fix(admin-ui): Fix team table filter dropdown transparency (#3625) @StephixOne
fix(medusa): execSync stdio (#3633) @carlos-r-l-rodrigues
fix(oas:test): Augment jest timeout from 30 to 60 sec (#3631) @patrick-medusajs
fix(medusa): Fix hanging inventory item migration script (#3624) @pKorsholm
fix(admin-ui): Eliminate purple from most-visible components (#3639) @olivermrbl
fix(admin-ui): Collapse categories by default (#3637) @olivermrbl
fix(admin-ui): Always show categories in product page (#3655) @olivermrbl

Chores

chore: Cleanup changesets and group fixes (#3543)
chore(medusa): remove PublishableAPIKeys feature flag (#3087)
chore(medusa): Improve store list products (#3252)
chore: Product page shows list of categories associated with it (#3400)
chore: Ignore admin-ui in core pipeline (#3381)
chore(medusa): remove PublishableAPIKeys feature flag (#3087)
chore(medusa): Improve store list products (#3252)
chore: Product page shows list of categories associated with it (#3400)
chore: Add missing changeset for @medusajs/modules-sdk
chore(create-medusa-app): Remove Admin + Gatsby starter from npx (#3376)
chore(medusa, modules-sdk): default module error message (#3605) @carlos-r-l-rodrigues
chore: Merge master to develop and manage conflict (#3570) @adrien2p
chore(medusa): EOL causing logging to hang (#3622) @olivermrbl
chore(admin-ui): Update favicon (#3640) @olivermrbl

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

v1.8.0

Preface

Introduction

Get Started

What’s new in 1.8?

Feature flags

Modules

Multi-warehouse

Nested Categories

Medusa Admin as a plugin

Event bus module

Cache module

Payment Processor API

OAS tooling and improvements

Types and Utils packages

Search plugins update

Performance improvements

Upgrade to Typeorm v0.3.11

Other noteworthy changes

What’s next?

Features

Bugs

Chores

Contributors