medusa

Building blocks for digital commerce

MIT License

Downloads
1.3M
Stars
24.9K
Committers
269

Bot releases are visible (Hide)

medusa - Medusa v2.0 Release Candidate #2

Published by olivermrbl 16 days ago

Get started with a new project

To get started using the RC, run the following command:

npx create-medusa-app@rc

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

Update existing project

Ensure your Medusa dependencies in package.json are using the rc tag:

{
  "dependencies": {
    "@medusajs/admin-sdk": "rc",
    "@medusajs/framework": "rc",
    "@medusajs/medusa": "rc",
    "@medusajs/medusa-cli": "rc",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Continued restructuring

[!WARNING]
Breaking change

Since the first RC, we have continued our code restructuring, this time affecting commonly used middleware. These have been moved from @medusajs/medusa to @medusajs/framework to make them usable outside the context of the core commerce package.

This is a breaking change if you are using any of the following middleware in your Medusa project:

  • applyParamsAsFilters
  • clearFiltersByKey
  • applyDefaultFilters
  • setContext
  • getQueryConfig
  • httpCompression
  • maybeApplyLinkFilter
  • refetchEntities
  • unlessPath
  • validateBody
  • validateQuery

Importing these middleware will look as follows going forward:

import { validateBody } from "@medusajs/framework/http"

Features

Bugs

Documentation

Chores

Other Changes

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.0-rc...v2.0.0-rc.2

medusa - Medusa v2.0 Release Candidate #1

Published by olivermrbl 19 days ago

We’re excited to share the first Release Candidate (RC) of Medusa 2.0. By definition, release candidates are not production-ready. There are likely still minor issues across our packages, which is part of the reason for publishing a pre-release of the official version.

We welcome feedback, questions, and bug reports. Please use Issues to submit your input.

Get started with a new project

To get started using the RC, run the following command:

npx create-medusa-app@rc

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

Highlights

Please note, the following highlights are based on changes that have landed between the last preview release update and this release candidate.

We will cover all new changes to Medusa 2.0 in the official release notes. For now, you can refer to previous preview release updates to see what's new.

Package restructuring

[!WARNING]
Breaking change

With the announcement of the first Release Candidate, we decided to perform some housekeeping tasks and arrange our packages/dependencies. This is the last larger breaking change before the official release of 2.0.

Our goal with this change is to reduce the footprint of multiple packages within your application. Instead, we expose all the core-level utilities via the @medusajs/framework package and all commerce features via the @medusajs/medusa package.

As a result, you will have fewer dependencies to install and upgrade with every change. We will also be able to restructure things internally without impacting outside usage.

Dependencies

Moving forward, the dependencies inside a fresh Medusa application's package.json file will look as follows:

{
  "dependencies": {
    "@medusajs/admin-sdk": "rc",
    "@medusajs/framework": "rc",
    "@medusajs/medusa": "rc",
    "@medusajs/medusa-cli": "rc",

    "@mikro-orm/core": "5.9.7",
    "@mikro-orm/knex": "5.9.7",
    "@mikro-orm/migrations": "5.9.7",
    "@mikro-orm/postgresql": "5.9.7",
    "awilix": "^8.0.1",
    "pg": "^8.13.0"
  },
  "devDependencies": {
    "@mikro-orm/cli": "5.9.7",
   
    "@swc/jest": "^0.2.36",
    "medusa-test-utils": "rc",
    "jest": "^29.7.0",

    "@types/node": "^20.0.0",
    "@swc/core": "1.5.7",
    "ts-node": "^10.9.2",
    "typescript": "^5.6.2",

    "@types/react": "^18.3.2",
    "@types/react-dom": "^18.2.25",
    "prop-types": "^15.8.1",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "vite": "^5.2.11"
  },
}

You don't have to install individual modules since they are all bundled and distributed via the @medusajs/medusa package.

TSConfig file changes

Now that most packages have been bundled into @medusajs/medusa and `@medusajs/framework, importing from the transitive dependencies should be done with subpaths.

For example, this is how a link definition will look like:

import HelloModule from "../modules/hello"
- import ProductModule from "@medusajs/product"
+ import ProductModule from "@medusajs/medusa/product"
- import { defineLink } from "@medusajs/utils"
+ import { defineLink } from "@medusajs/framework/utils"

export default defineLink(
  ProductModule.linkable.product,
  HelloModule.linkable.myCustom
)

In the above example, we import the product module from the @medusajs/medusa/product subpath and the defineLink from the @medusajs/framework/utils subpath.

To use subpath imports, the moduleResolution should be set to Node16 inside the tsconfig.json file:

{
  "module": "Node16",
  "moduleResolution": "Node16",
}

medusa-config.js file changes

With the introduction of subpath imports, the module registration in medusa-config.js should similarly use subpaths instead of top-level paths.

For example, this is how you would register the authentication module:

defineConfig({
  // ...
  modules: {
-  resolve: "@medusajs/auth",
+  resolve: "@medusajs/medusa/auth",
    options: {
      providers: [
        {
-         resolve: "@medusajs/auth-emailpass",
+         resolve: "@medusajs/medusa/auth-emailpass",
          id: "emailpass",
          options: {
            // provider options...
          },
        },
      ],
    },
  },
})

Notice the change from @medusajs/auth to @medusajs/medusa/auth and @medusajs/auth-emailpass to @medusajs/medusa/auth-emailpass.

Features

Bugs

Documentation

Chores

Other Changes

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.10-preview...v2.0.0-rc

medusa - Preview Release Update #10

Published by olivermrbl about 1 month ago

Update existing project

Ensure your Medusa dependencies in package.json are using the preview tag:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Introduced a new query tool

We have introduced a new tool, Query, for querying data across modules in your application. Over time, it will replace Remote Query, which has been deprecated in the latest version. The underlying query engine of Query and Remote Query is the same, but we have changed the query API and eliminated redundant configurations that had built up over time.

There are two significant differences between the two tools:

  • The result returned by Query takes the same shape regardless of the query input, which is different from that of Remote Query's that differed depending on whether pagination was applied or not.
  • The call signature of Query is query.graph({ ... }), which is different from Remote Query's query({ ... })

Query Result

With Query, you will always receive a result with data and metadata. The data contains your requested resources and the metadata contains information about the applied pagination. We recommend consuming it like so:

const { data, metadata } = await query...

Call signature

With Query, you query data across your modules with query.graph({ ... }).

For example, in an API Route, the difference between how you consume Query vs. Remote Query is as follows:

// API Route
-const query = req.container.resolve(ContainerRegistrationKeys.REMOTE_QUERY)
- 
-const result = await query({ ... })
+const query = req.container.resolve(ContainerRegistrationKeys.QUERY)
+
+const { data, metadata } = await query.graph({ ... })

Migrating to Query

To migrate from Remote Query to Query, the following changes are needed:

  • Resolve query instead of remoteQuery from the dependency container
  • Use query.graph({ ... }) instead of query({ .. })
  • Update query options to fit the new format*

*The changes to the query options format are:

  • Entrypoint has been renamed: entryPoint -> entity
  • Filters has been moved to a top-level option: variables: { filters: { ... } } -> filters: { ... }
  • Pagination has been moved to a top-level option: variables: { pagination: { ... } } -> pagination: { ... }
  • Context has been moved to a top-level option: variables: { context: { ... } } -> context: { ... }
  • Variables has been removed entirely from the API

Here's an example using all options:

const { data, metadata } = await query.graph({
  entity: "product",
  fields: ["id", "title", "variants.calculated_price"],
  filters: { 
    variants: { 
      sku: "SHIRT-1234" 
    },
  },
  pagination: { take: 10, skip: 0 },
  context: {
    variants: {
      calculated_price: QueryContext({ currency_code: "usd" })
    }
  }
})

In this example, we:

  • Retrieve the first 10 products that match our query
  • Only with the fields: id, title, and the calculated price of variants, variants.calculated_price
  • Filtered by product variants sku
  • With computed variant prices based on a dynamic QueryContext

Alongside the tool, we have shipped a new option, types, to our CLI commands start and develop. If specified, we will attempt to generate types for all data models in existing and custom modules in your project and place them in a new top-level folder .medusa in your project. The types should significantly improve the developer experience of Query by giving you intellisense of the data you can query in your application.

You can read more about Query in our documentation.

Remote Query will be removed in a later preview version and will not be part of the official release of Medusa 2.0. However, because the required changes are minimal, we recommend upgrading now to avoid issues in the future.

Introduced observability

We have introduced observability into our framework, enabling traces for HTTP requests, workflow executions, and database queries. Our instrumentation is built on top of OpenTelemetry, which allows you to export traces to any platform compatible with OpenTelemetry events.

Read more about tracing in Medusa and how to get started in our documentation.

Features

Bugs

Documentation

Other Changes

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.9-preview...v2.0.10

medusa - v2.0.9-preview

Published by olivermrbl about 1 month ago

Update existing project

Ensure your Medusa dependencies in package.json are using the preview tag:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Deprecated ModuleRegistrationName

[!WARNING]
Breaking change

We have deprecated ModuleRegistrationName in favor of Modules. ModuleRegistrationName will be removed in a later preview release.

Modules are registered in the dependency container using these keys and are now resolved as follows:

import { Modules } from "@medusajs/utils"

const productModule = container.resolve(Modules.PRODUCT)

This is a breaking change if you have used strings for module resolution instead of ModuleRegistrationName.

For example, if you have resolved the product module using its previous string resolution key, you will need to change it as follows:

-const productModule = container.resolve("productModuleService")
+const productModule = container.resolve(Modules.PRODUCT)

Enforced Publishable API Key in Store API

[!WARNING]
Breaking change

In the latest preview release, we require a Publishable API key header to access the Store API, i.e., all endpoints under the /store resource. This will ensure your requests are scoped to at least one Sales Channel associated with the Publishable API key. Sales Channels are used to retrieve products, retrieve correct inventory quantities, create carts, and place orders.

The requirement has been introduced to ensure you can perform these operations without experiencing issues.

Disabled automatic MikroORM casing change

[!WARNING]
Breaking change

Refer to https://github.com/medusajs/medusa/pull/9058 for a description of the issue, solution, and the minimal breaking change.

Fixed issue with many-to-many relations

[!WARNING]
Breaking change

In #9075, a bug with our many-to-many relation definition was identified. The solution to the problem lead to a minimal breaking change to the way many-to-many relations are defined when using our model tool from @medusajs/framework.

We now require the many-to-many relation to be defined on both sides and a mappedBy definition on at least one side.

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.8-preview...v2.0.9-preview

medusa - v1.20.10

Published by olivermrbl about 1 month ago

Bugs

Documentation

Full Changelog: https://github.com/medusajs/medusa/compare/1.20.10...v1.20.11

medusa - v2.0.8-preview

Published by olivermrbl about 1 month ago

Update existing project

Ensure your Medusa dependencies in package.json are using the preview tag:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Restructured admin packages

| 🚧 Breaking change

Our admin packages have been restructured in https://github.com/medusajs/medusa/pull/8988. This is a breaking change, as our extensions tool has been moved to a new package.

More specifically, defineWidgetConfig and defineRouteConfig should be imported from @medusajs/admin-sdk instead of @medusajs/admin-shared.

- import { defineRouteConfig, defineWidgetConfig } from "@medusajs/admin-shared"
+ import { defineRouteConfig, defineWidgetConfig } from "@medusajs/admin-sdk"

Additionally, the new admin package needs to be an explicit dependency in your project, so you should install it with your preferred package manager:

yarn add @medusajs/admin-sdk@preview

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.7-preview...v2.0.8-preview

medusa - v2.0.7-preview Latest Release

Published by olivermrbl about 2 months ago

Highlights

Bulk Editor improvements

We have added error handling to our bulk editor to make bulk editing of resources more manageable.

https://github.com/user-attachments/assets/f5d29b35-e488-4b79-826f-662b9f7bf50f

Order Exchanges, Returns, and Claims

We have finished the first iteration of Order Exchanges, Returns, and Claims. There is still some polishing to do on these flows, so please report any issues you find.

Recipe: Food-Delivery platform

We have published a new recipe taking you though building a food-delivery platform like UberEats.

We also have a demo project and repository if you are curious to dig into how this recipe is used in practice: https://github.com/medusajs/medusa-eats

Remote Joiner alias conflict

🚧 Breaking change

Several models were named the same across modules, causing conflicts for our Remote Joiner engine. To resolve the issues with Remote Joiner, the name-clashing models have been renamed to be specific to the module they belong to.

Only the ORM models have been renamed – not the underlying tables.

Order Module:

  • Address -> OrderAddress
  • LineItem -> OrderLineItem
  • LineItemAdjustment -> OrderLineItemAdjustment
  • LineItemTaxLine -> OrderLineItemTaxLine
  • ShippingMethod -> OrderShippingMethod
  • ShippingMethodAdjustment -> OrderShippingMethodAdjustment
  • ShippingMethodTaxLine -> OrderShippingMethodTaxLine
  • Transaction -> OrderTransaction

Fulfillment Module:

  • Address -> FulfillmentAddress

These changes affect the modules' methods since we auto-generate methods based on the model names. For example, createLineItem in the Order Module is now createOrderLineItem. More specifically, this change affects the models mentioned above, and the following methods of those:

  • retrieve[ModelName]
  • list[ModelName]
  • listAndCount[ModelName]
  • create[ModelName]
  • update[ModelName]
  • delete[ModelName]
  • softDelete[ModelName]
  • restore[ModelName]

Internal module events

We have decided to hide the logs of internal module events. These events are currently only emitted in a few modules and are not supposed to be used by end-users for subscribers and such. You should always use Workflow Events, which have replaced the event concept from V1.

Features

Bugs

Documentation

Chores

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.6-preview...v2.0.7-preview

medusa - v2.0.6-preview

Published by olivermrbl about 2 months ago

Highlights

Introduced identity registration in auth domain

🚧 Breaking change

We have separated identity registration from authentication. For context about why this decision was made see #8683.

Introduced endpoint /auth/[scope]/[provider]/register

We have added an endpoint specifically for registering new identities. This change will only be used by providers that require registration, such as email-password.

Introduced method register in auth provider and auth module

We have introduced a new method register to the auth provider and auth module interfaces. This change will only be used by providers that require registration, such as email-password.

Examples of new authentication flows

Sign up with email-password:

POST /admin/invites -> admin creates invite
POST /auth/user/emailpass/register -> user registers identity
POST /admin/invites/accept -> invite is accepted passing the invite + auth token 

Sign in with email-password:

POST /auth/user/emailpass -> authenticate with email-password
GET /admin/users/me -> get authenticated user

Sign up with Google:

POST /auth/user/google -> redirects to Google auth
POST /auth/user/google/callback -> Google hits callback URL, authenticates, and responds with user
POST /admin/invites/accept -> invite is accepted passing the invite + auth token 

Sign up with Google:

POST /auth/user/google -> redirects to Google auth
POST /auth/user/google/callback -> Google hits callback URL, authenticates, and responds with user
GET /admin/users/me -> get authenticated user

Sign up as customer with email-password:

POST /auth/customer/emailpass/register -> customer registers identity
POST /store/customers -> customer is created

Sign in with email-password:

POST /auth/customer/emailpass -> authenticate customer with email-password

CLI commands to manage database operations

We have added a new namespace to our CLI specifically for database operations db:.

Alongside the namespace, a range of new commands have been introduced:

  • db:create: The command creates the database (if it is missing) and updates the .env file
  • db:migrate: This command will run the migrations and sync the links, unless --skip-links flag is specified
  • db:rollback: Rolls-back last batch of migrations for one or more selected modules
  • db:generate: Generates migrations for one or more selected modules
  • db:sync-links: Ensures links between modules are in sync

Events

We have (re)introduced events in the product domain:

"product-category.created"
"product-category.updated"
"product-category.deleted"
"product-collection.created"
"product-collection.updated"
"product-collection.deleted"
"product-variant.updated"
"product-variant.created"
"product-variant.deleted"
"product.updated"
"product.created"
"product.deleted"

Documentation: Redesign completed

We have completed redesigning our documentation for Medusa 2.0, which includes an updated layout and a range of new components improving the overall user experience.

Explore the updated documentation here.

Documentation: Re-introduced AI assistant (beta)

We have (re)introduced our AI assistant for Medusa 2.0 to help guide you through our documentation and find what you are looking for as fast as possible.

Try out the new AI assistant here.

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.5-preview...v2.0.6-preview

medusa - v1.20.10

Published by olivermrbl about 2 months ago

Bugs

Docs

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.9...1.20.10

medusa - v2.0.5-preview

Published by olivermrbl 2 months ago

Highlights

Product Category organizer component

We've polished the Product Category organizer component for a smoother drag-and-drop experience. As part of the polish, we've also fixed an issue with a dependency.

Email-pass as default authentication provider

🚧 Breaking change

We've updated the default modules config to include email-password as a default authentication provider. This is a breaking change. To ensure your application will continue to run, you should install the preview version of the email-password provider package:

yarn add @medusajs/auth-emailpass@preview

Workflows Reference

We've introduced a reference of all workflows used in Medusa's core. It includes a visual representation of steps, hooks, and conditionals.

Explore the reference here.

Features

Bugs

Documentation

Chores

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.4-preview...v2.0.5-preview

medusa - v2.0.4-preview

Published by olivermrbl 2 months ago

Highlights

Domain-specific Workflow Hooks

We recently introduced Workflow Hooks, allowing you to expose injection points in workflows for the consumer to perform custom logic.

Among Medusa's core workflows, you will find available hooks in the following domains:

  • Products: create, update, and delete
  • Orders: create, cancel, complete, create fulfillment, cancel fulfillment, and create shipment
  • Promotions: create, update, delete, create campaign, update campaign, and delete campaign
  • Carts: create and update
  • Customers: create, update, delete, create address, update address, and delete address

Workflow hooks are consumed by registering a hook handler on the workflow. The hook handlers should be placed and registered in the /workflows/hooks folder of your Medusa project. For example, here's how to use the product-created hook:

// workflows/hooks/product-created.ts
import { createProductsWorkflow } from "@medusajs/core-flows"

createProductsWorkflow.hooks.productCreated(( { products, additional_data }) => {
  // run custom business logic
})

This hook receives the created products and arbitrary additional_data. The latter should be passed to the workflow upon running it:

await createProductsWorkflow(req.scope).run({
  input: { products: [ ... ], additional_data: { ... } },
})

In combination with extending the request payload to receive additional data, you can achieve a range of different use cases with Workflow Hooks, e.g. linking a product with another resource. We will share recipes for many of these cases in the near future.

We will continuously add more Workflow Hooks to our core workflow, e.g. a hook to transform line item data and price before it's added to the cart. Keep an eye out for our preview release updates, as they will contain an overview of the new hooks.

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.3-preview...v2.0.4-preview

medusa - v2.0.3-preview

Published by olivermrbl 3 months ago

Get started with a new project

To get started using the preview release, run the following command:

npx create-medusa-app@preview

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

Highlights

Workflow Hooks

🚧 Breaking change

We have added a new helper, createHook, to the workflows-sdk. The createHook helper exposes a hook from a workflow. Later (after the workflow has been composed), the workflow consumers can bind a handler to the hook to run custom logic.

[!NOTE]
As of now, you can only register one hook handler, and the workflow orchestrator ignores the return value.

Exposing hook via createHook

import {
  createStep,
  createHook,
  createWorkflow,
  WorkflowResponse
} from '@medusajs/workflows-sdk'

const createProductStep = createStep('createProduct', function () {
  // business logic for "createProduct"
})

const workflow = createWorkflow('name', function (input) {
  createProductStep(input)
  const productCreatedHook = createHook('productCreated', { productId: input.id })

  return new WorkflowResponse(input, {
    hooks: [productCreatedHook]
  })
})

Points to note

  • Unlike the createStep function, the createHook method is called within the workflow composition callback.
  • You must return the created hooks from the composition callback. Returning of hooks is needed for the TypeScript engine to provide intellisense when registering a handler for the hook.
  • Hooks are executed in the same position as they are defined within the composition callback

Registering the hook handler
The workflow user must register a hook handler to run custom logic within a workflow. They can do that as follows.

workflow.hooks.productCreated(() => {
  // run custom business logic
})

Points to note

  • The hook handler behaves similarly to a workflow step. It can run async code, will be retried, and can also have compensation behavior (defined as the 2nd parameter)
  • There can only be one handler for a hook. If you need multiple handlers, you should create another workflow and register that as the hook handler (not supported yet).
  • The return value of the hook handler is ignored in this first iteration.

Introducing the WorkflowResponse class and breaking changes

The introduction of hooks has changed the return value of the createWorkflow composition callback. Now, we must return both the workflow results and the configured hooks.

Instead of manually composing the return value, you can use the WorkflowResponse class to construct the current response. The WorkflowResponse class accepts the following parameters.

  • The first parameter is the result of the workflow.
  • The second parameter (optional) is a config object with configured hooks.

Product Import and Export

We have re-introduced Product Import and Export and simultaneously redesigned the notifications drawer in the dashboard.

Right now, we are polling for new notifications every third second, but we intend to introduce SSE (or a similar tech.) to enable real-time notifications.

Product Tag management UI

We have added Product Tag management in the dashboard. Find it in "Settings > Product Tags".

New Recipes: Subscriptions and Digital Products

We have added two new recipes covering how to add support for Subscriptions and Digital Product respectively. They both come with an example repository.

Check out the Subscription recipe here.

Check out the Digital Products recipe here.

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.2-preview...v2.0.3-preview

medusa - v1.20.9

Published by olivermrbl 3 months ago

Fixes

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.8...v1.20.9

medusa - v2.0.2-preview

Published by olivermrbl 3 months ago

Get started with a new project

To get started using the preview release, run the following command:

npx create-medusa-app@preview

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

Update existing project

Ensure your Medusa dependencies in package.json are using the preview tag:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Migrations and Linking CLI

We have introduced new CLI commands for generating migrations and managing links between modules. The latter is used to ensure links are in sync.

To generate migrations in your module, you can run the following command:

npx medusa migrations generate <name of module>

To sync the links between modules, you can run the following command:

npx medusa links sync

In case your links are out of sync, you'll be guided through possible actions to take.

Explore our full CLI reference in our documentation.

New Middlewares API

🚧 Breaking change

We have introduced a new way of defining middlewares for API Routes. This is a breaking change.

Instead of exporting a config from middlewares.ts, you will now need to use a new utility function defineMiddlewares.

To upgrade your project, you should apply the following changes:

- import { MiddlewareConfig } from '@medusajs/medusa'
+ import { defineMiddlewares } from '@medusajs/medusa'

- export const config: MiddlewareConfig = {
-   routes: []
- }
+ export default defineMiddlewares({
+  routes: []
+ })

Read more about the new Middlewares API in our documentation.

Tax-inclusive Pricing

We have re-introduced tax-inclusive pricing. Tax-Inclusive pricing allows you to set the final prices for products and shipping options regardless of the customer's applicable tax rates. When tax-inclusive prices are used, Medusa automatically calculates the tax amount for a given price.

Read more about tax-inclusive pricing in our documentation.

Coming soon

The following are work-in-progress and will be released soon:

  • Returns, Exchanges, and Claims of Orders
  • Export and Import of Products
  • Bulk Editor improvements
  • Digital Products and Subscription Recipes

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0.1-preview...v2.0.2-preview

medusa - v1.20.8

Published by olivermrbl 3 months ago

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.7...v1.20.8

medusa - v2.0.1-preview

Published by olivermrbl 3 months ago

Get started with new project

To get started using the preview release, run the following command:

npx create-medusa-app@preview

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

Update existing project

Ensure your Medusa dependencies in package.json are using the preview tag:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

Highlights

Migrations CLI

🚧 Breaking change

The migrations workflow and CLI output have changed. Here's a summary of the changes.

  • The commands remain the same as npx medusa migrations run and npx medusa migrations revert
  • The CLI output has been changed to be more visually appealing and add separate migrations logs for each module with a line break

Breaking changes

The revert command has a breaking change that it requires one or more module names to perform the revert. It means, the action revert is not valid at the global/app level. It must be executed on a specific module.

If you are developing a custom module, you can run the revert command for it as follows:

# helloWorld is the moduleName
npx medusa migrations revert helloWorld

When-then utility for conditional execution of steps in Workflows

We have added a new when-then utility to execute steps conditionally.

Here's a basic example of its usage within a workflow:

const workflow = createWorkflow("workflow", function (input) {
    
    const result = when(input, (input) => {
      return input.someConditionalData
    }).then(() => {
      const otherResult = someStep({ ... })
      return otherResult
    })

    return someOtherStep(result)
  }
)

Tax Regions UI update

The Tax Regions domain in Medusa Admin has been revamped, improving the overall UI and UX.

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v2.0-preview...v2.0.1-preview

medusa - v2.0-preview

Published by olivermrbl 4 months ago

Medusa 2.0 Public Preview Release

Today, we’re excited to share a Preview Release of Medusa 2.0.

The following document covers resources, guides, and things to know about the first preview release of Medusa 2.0. It will help you get started and give you a high-level overview of your new Medusa 2.0 application and what’s still to be done.

The preview release is not ready for production and is only intended for experimentation and development of new projects.

The release candidate later this year will include more fully-fledged resources for 2.0, including an overview of breaking changes, migration guides, and much more that will ensure a smoother onboarding.

We advise against upgrading your project to 2.0 at this point, as we are still working on documentating the best possible path.

These release notes are only intended to help you start and introduce you to your new Medusa 2.0 project. For a more in-depth exploration of the major upgrade, refer to our new documentation.

We are publishing this release to solicit early user and community feedback. Please file Issues for bug reports and/or submit Discussions with input or questions.

We thank you all very much in advance.


Get started

To get started using the preview release, run the following command:

npx create-medusa-app@preview

This command will create a new Medusa project with our redesigned admin and a 2.0-compatible Next.js storefront. The Medusa application and the Next.js storefront are separate projects in separate folders.

The folder structure of Medusa projects has changed:

my-project
 ├── src
 │   ├── admin
 │   ├── api
 │   ├── jobs
 │   ├── subscribers
-│   ├── services
-│   ├── models
-│   ├── migrations
-│   ├── loaders
+│   ├── modules
+│   │   └── my-module
+│   │       ├── loaders
+│   │       ├── migrations
+│   │       ├── models
+│   │       ├── index.ts
+│   │       └── service.ts
+│   ├── workflows
 └── medusa-config.ts

The modules folder replaces a lot of folders from a 1.0 project and will contain most business logic customizations in your Medusa 2.0 application. We highly encourage you to read the section of our docs covering this new concept in detail.

The workflows folder holds your custom workflows. Workflows are a fundamental concept in cross-module operations and a core element of Medusa 2.0. Read more about workflows here.

Additionally, medusa-config.js has been cleaned up and improved with a new type-safe utility function for defining the config for your Medusa project. The file can also now live as both a JS and TS file.

export default defineConfig({
  projectConfig: {
    http: {
      storeCors: "<STORE_CORS>",
      adminCors: "<ADMIN_CORS>",
      authCors: "<AUTH_CORS>"
    },
    redisUrl: "<REDIS URL>",
    databaseUrl: "<DATABASE_URL>",
  },
  admin: {
    backendUrl: "https://my-medusa-server.medusajs.app",
  },
})

You are now ready to explore all the new features in the preview release. However, we recommend reading through our documentation to fully understand what is new in 2.0 and how it differs from 1.0.

Additionally, you can find references and code snippets for our tools in our Learning Resources.


Keeping up with preview releases

We release preview versions every three hours. We recommend setting the version of your Medusa dependencies to preview, so you can regularly update without knowing specific version numbers.

All your Medusa dependencies in package.json should look something like this:

{
  "dependencies": {
    "@medusajs/medusa": "preview",
    "@medusajs/pricing": "preview",
    "@medusajs/product": "preview",
    ...
  }
}

To ensure an upgrade to a new version is completed correctly, run the following sequence of commands:

rm -rf node_modules
rm yarn.lock // or package-lock.json

yarn // If you are using yarn berry, you need to create the lock-file first

What’s new?

Medusa 2.0 is a huge upgrade, in fact, the biggest upgrade since we open-sourced the project four years ago. The upgrade comes with many new features and improvements, some of which are still work-in-progress. In the following sections, we will briefly cover these features and the parts of the product still subject to change. A more detailed changelog will be released as part of the release candidate and, subsequently, the official release later this year.

Admin dashboard

Our admin dashboard has been completely overhauled, improving its overall look and feel to provide end-users with a more cohesive and consistent experience.

Additionally, we have migrated away from Webpack to Vite, which improves the developer experience with features like HMR and allows us and our users to tap into a rich and flourishing community and plugin ecosystem.

Read more about the admin dashboard and its extension capabilities here.

A few admin flows have yet to be built. This is primarily around returns, exchanges, claims, and order edits. We expect to finalize these in the coming weeks.

Modules architecture

Our modules foundation has been re-architected to entirely decouple modules from one another, enabling greater composability, a new standalone usage mode, and a more approachable incremental adoption of Medusa.

Read more about the architecture refactor in our 2.0 announcement from earlier this year.

New commerce features

We saw reworking the module's architecture as an opportunity to rethink the feature set of some of the business domains in Medusa 1.x. As a result, we are excited to introduce a range of advanced capabilities across a series of modules. Here are a few noteworthy improvements:

  • Stock location: Build omnichannel experiences with new stock location features, including “Buy online, pick up in-store” options.
  • Inventory: Compose multi-part variants and share inventory across products with our new inventory management features
  • Authentication: Enable authentication with external providers, such as Google, with our new authentication and user management features
  • Promotion: Create granular promotions with our new rules engine. Use conditions to create bundled discounts, buy-get, spend-get, temporary campaigns, and more

Many other modules have also seen improvements. Browse through all of them in our learning resources.

Data modeling language

A core feature of Medusa is the ability to extend the default commerce application with additional business logic to cater to a specific use case, natively integrate with third-party providers, replace existing domains, and more.

At the core of extensions in Medusa 2.0 are modules, and at the core of modules are data models. Data models define the concepts living within your application. In our commerce modules, you find orders, products, customers, promotions, etc. By introducing your own data models, you extend this semantic layer of your application, enabling you to build features and custom workflows by integrating existing and new concepts. Because data models are at the core of every customization, we decided to make them easier to work with.

We are excited to announce a new data modeling language in Medusa 2.0 that will improve the experience of defining and working with data in your application. You can read more about the new feature here.

Below is a simple example of what data models will look like in 2.0:

Long-running Workflows

We are excited to extend our existing workflow capabilities with Long-running Workflows for processing long-running operations in the background. Instead of synchronously receiving a workflow's result, Long-running Workflows are subscribed to for status changes and execution progress. Additionally, the Long-running Workflows comes with an API for programmatically moving from one step to the next. These features make Long-running Workflows a great fit for use cases that require a human-in-the-loop or operations with a varying long-running execution time.

For example, we use Long-running Workflows extensively to build the infrastructure provisioning of Medusa Cloud.

Alongside the Long-running Workflows, we are also introducing a new admin section for managing them. Here, you can see currently executing and completed workflows, providing full transparency into your long-running operations.

Medusa 2.0 comes with much more than what is highlighted in this post. We will cover everything in-depth in the official release notes.


These release notes are published as a GitHub Discussion as well for comments and questions on the preview release.

medusa - v1.20.7

Published by olivermrbl 4 months ago

Highlights

Duplicate workflow registration no longer throws

Workflows are not utilized in v1.x, however our core package comes with a few workflows for v2.0. We are currently investigating an issue with checking for duplicate workflow registrations, but we can safely remove this check in v1.x, as it will never affect users using these versions.

Isolation level in batch job subscriber

The transaction isolation level set by the batch job processing subscriber has been changed from the default "READ COMMITTED" to "REPEATABLE READ" to ensure correct data in long-running job processors.

This was always the intention, but the "REPEATABLE READ" level set in the batch job strategies was overwritten by the default level set in the subscriber calling the strategy. This happens because the subscriber initiates a transaction with the default level that is then reused within the strategies.

Bugs

Docs

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.6...v1.20.7

medusa - v1.20.6

Published by olivermrbl 6 months ago

Highlights

Resolves several issues in @medusajs/admin

  • Add default value for host option in @medusjs/admin.
  • Updates the version of tailwindcss, autoprefixer, and postcss in @medusajs/admin-ui, to avoid issues when importing components using tailwindcss@4.
  • Fixes an issue in @medusajs/medusa where the develop command would throw an error when @medusajs/admin was not installed.

https://github.com/medusajs/medusa/pull/7203

Bugs

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.5...v1.20.6

medusa - v1.20.5

Published by olivermrbl 6 months ago

Highlights

Preview release of Medusa 2.0 next week

We recently announced Medusa 2.0, and the majority of our time and resources are currently going into making this new major a reality as soon as possible. We will reach an important milestone next week by releasing an early preview version for experimentation and exploration. More information about the preview version will be shared alongside the release.


Remove useToast hook from @medusajs/ui

🚧 Breaking change

The useToast hook has been removed. Users should instead use the toast function that is exported from the @medusajs/ui package. This function can be used to show toasts in your application. For more information on how to use the toast function, please refer to the documentation.

The Toaster component is still available but the options for the component have changed. The default position has been changed to bottom-right. For more information on the Toaster component, please refer to the documentation.

Order totals account for deleted discounts

An issue with order totals not accounting for deleted discounts has been resolved.

https://github.com/medusajs/medusa/pull/6837

Resolve node-gyp installation issue in @medusajs/admin

An issue with node-gyp in a dependency of a dependency has been resolved. The solution should, for the time being, be considered temporary.

https://github.com/medusajs/medusa/pull/6952

Expose backend URL for admin in local development

The forced backend URL for admin in local development has been removed in favor of a plugin configuration.

You can now specify a host value:

// medusa-config.js
const plugins = [
  ...
  {
    resolve: "@medusajs/admin",
    options: {
      // other options...
      develop: {
        port: 7000,
        host: "example.com",
      },
    },
  },
]

https://github.com/medusajs/medusa/pull/7128

Features

Bugs

Documentation

Chores

New Contributors

Full Changelog: https://github.com/medusajs/medusa/compare/v1.20.4...v1.20.5