Comment from @olivermrbl:
What
In Q1 2023, we will revisit our Product API and begin to extend its capabilities. In the first iteration, we will introduce Nested Categories (see RFC (TBA)), and later we will add support for custom fields. We are likely to start scoping the Custom Fields API in mid-Q1.

OP
I checked the admin demo and could see no way to add custom attributes for products. Did I miss something or would this need to be done via code?

backlog

Custom Fields API

Comment from @olivermrbl:
What
We've included Multi-language support in our roadmap and will likely start scoping mid-next year.

OP
Hello, would be nice to have multi-language support. It will make it much easier to manage content for multi-language stores.

Multi-language support

What
Introduce a Medusa Admin component library, that will allow plugin-builders to create components at ease.

Admin Component library

Migrating to Typeorm V3

What
Improve our logging system by introducing an advanced Tracing API that works in a distributed architecture

Improve internal Tracing and Logging

What
Add a storefront component library containing implementations of the more complex customer flows e.g. checkout.

Storefront Component library

What
Support for running Medusa in a serverless environment

Serverless deployments

What
In our efforts to support a broader range of payment providers, we will introduce a Checkout API defining the interface for payment providers that combines authorization and capture in a single step e.g. PayPal, GooglePay, ApplePay.

Checkout API

What
Introduce an API that allows for advanced reporting on merchant operations

Reporting API

What
Allow store operators to edit orders after it has been placed by a customer
Motivation
Allow placed orders to be edited by store operators to eliminate the need for canceling orders if an order is placed that needs changes. This may happen in a few scenarios e.g.:

Stock discrepancies result in an order coming in with OOS items
Customer changes their mind after placing an order

completed

feature flagged

Order Editing API

What
Allow merchants to collect payments for arbitrary cases e.g. discrepancies on Orders
Motivation
With the introduction of Order Edits, we allow merchants to edit an open order. Those edits could lead to payment discrepancies. The Payment Collection API serves as a way to collect payment for such cases (and many others in the future).

Payment Collection API

What
Use Publishable Keys to determine which resources can be requested from a particular client
Motivation
Requesting products from a specific Sales Channel currency requires you to add sales_channel_id as a query param to all API calls, which is a tedious task and a bad developer experience. Publishable Keys aims to introduce more robust and scalable support for scoping resources and to allow for a better client experience by allowing a Publishable Key to be defined in a single place.

Publishable Keys API

What
Allow developers to build custom components for the admin system in their local project or plugins

planned

Extensible Admin

What
Introduce a CacheService abstraction allowing businesses to use any cache provider to power the caching mechanism in Medusa

Cache module

What
Introduce a concept Category in the products domain and allow merchants to create nested relationships
Motivation
In our continuous efforts to extend our Products API, we will introduce categories. This will allow merchants to expose more granular customer-facing search capabilities.
Technical design
RFC

started

Nested Categories

What
Allow merchants to manage inventory across locations and enable new customer experiences
Motivation
Merchants with multiple stock-keeping locations want to manage their inventory at each location and make it available for different sales channels and fulfillment methods. Currently, Medusa only holds a single inventory count. This forces merchants to either make heavy customizations to Medusa or use 3rd parties if they need to make fulfillments across locations or restrict inventory across locations.

Multi-warehouse API

What
Shipping Medusa Admin as a core plugin through npm to allow for versioning
Motivation
Medusa Admin is currently a separate entity from the core. More often than not, this is frustrating for our users, as they may experience issues due to a version mismatch between Medusa Admin and the core package.
Right now, if you want to avoid upgrading admin, you'll have to dig out the specific commit that is compatible with your version of Medusa. This is not ideal and generally a bad developer experience.
To address these issues, we are bringing the admin closer to the core project by deprecating the separate admin repository and moving the admin to our monorepo. This allows us to version Medusa Admin similarly to all other packages. Going forward, you'll be able to match your core Medusa version with a specific Medusa Admin version ensuring compatibility.

Admin as `npm` package

What
In our efforts to support a broader range of payment providers, we will introduce a Payment Processor API defining the interface for payment providers with a traditional authorization -> capture flow e.g. Stripe.

Payment Processor API

What
Leverage our OAS to generate types and ship them separately from the core
Motivation
Main motivation: Manually maintaining API clients is time-consuming and error-prone. Time that could be spent on more valuable efforts
Secondary motivation: Reduce direct imports from Medusa core package in clients and apps. These direct imports sometimes have side effects, likes pulling unnecessary dependencies into clients and apps.

Separating types from the core

What
Introduce an EventBus abstraction allowing businesses to use any PubSub provider to power the event's infrastructure in Medusa
Motivation
With our current architecture, you are forced to have Redis as part of your stack if you want to leverage the events system in Medusa. Ideally, the events system should not be tied to a specific provider, such that if your existing infrastructure contains a PubSub provider different from Redis (e.g. RabbitMQ), you can use it to power Medusa's events system.

EventBus module

In our Roadmap, you'll find the following labels in use:

Started - Actively worked on. Expect to complete within two months.
Planned - Confidence in the technical design of the feature. Work will commence within two months.
Backlog - No technical design. We are doing light validation of the feature.
Completed + Feature Flagged - Feature has been released but is still guarded by a feature flag
Completed - Feature has been released

Roadmap.

Started

Planned

Completed

Backlog