Skip to content

Releases: medusajs/medusa

Medusa 2.0 Release Candidate #4

14 Oct 15:17
ebb16d6
Compare
Choose a tag to compare

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

Removed deprecated APIs

Warning

Breaking change

We are still cleaning up in preparation for v2.0 and this release removes a range of deprecated APIs.

Here is a list of everything:

Commands

  • seed: There was no implementation for the seed command in the first place.
  • migrations [action]: Removed in favor of db:migrate, db:rollback and db:generate.
  • links [action]: Removed in favor of db:sync-links.
  • start-cluster: Removed start-cluster command in favor of the --cluster flag on the start command.

Config options

  • Remove config option databaseType as it is not used anywhere.
  • Remove config option httpCompression in favor of compression property.
  • Remove allowedFields in favor of allowed property from the MedusaRequest.
  • Remove expand property in favor of allowed property from the RequestQueryFields.
  • Remove defaultFields and defaultRelations in favor of defaults property from the RequestQueryFields.
  • Remove allowedFields and allowedRelations in favor of allowed property from the RequestQueryFields.

Events build

  • Remove eventsEnum in favor of eventName property accepted by the moduleEventBuilderFactory. Also updated all the usages to use eventName.

ModelDTO

  • Remove unused properties singular and plural from ModelDTOConfig.

Models template

  • Remove unused properties create, update, singular, and plural from ModelsConfigTemplate.

Zod validator

  • Remove unused OptionalBooleanValidator in favor of booleanString.

Features

Bugs

Documentation

Chores

  • chore(framework): update TSDocs for medusa config by @shahednasser in #9559
  • chore(product): Update the events emitted from the product module by @adrien2p in #9557

Full Changelog: v2.0.0-rc.3...v2.0.0-rc.4

Medusa 2.0 Release Candidate #3

14 Oct 09:00
11120a8
Compare
Choose a tag to compare

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

Standalone builds

Warning

Breaking change

As part of our preparations for the official release, we have improved our build process by introducing standalone builds. Now, when you build your Medusa project, we compile it within the project and mimic the file structure in the build output, not just the src directory. Additionally, we are placing the build artifacts in .medusa in the server and admin folders for the backend and dashboard code, respectively.

Here's how the build output looks like

.medusa
├── server
│   ├── package.json
│   ├── yarn.lock
│   ├── medusa-config.js
│   ├── modules
│   │   ├── hello
│   │       ├── index.js
│   ├─── model
│   ├─── index.js
├── admin
│   ├── assets
│   ├── index.html
└── types

If you notice carefully, medusa-config.js, yarn.lock, and package.json is included in the build artifacts. We do so to create a standalone built application, something you can copy/paste to your server and run without relying on the original source code.

This results in small containers since you are not copying unnecessary files. Additionally, it clearly distinguishes between the development and production code. If you want to run the production server, then cd into the .medusa/server directory and run it from there.

Breaking changes (summarised):

  • Remove the dist and build folders. Instead, write them production artifacts within the .medusa directory as .medusa/admin and .medusa/server.
  • Change the output of the .medusa/server folder to mimic the root project structure.

Read more in the PR.

Module registration

Warning

Breaking change

We have cleaned up module registration in medusa-config.js to be consistent with the rest of the configuration. This means modules can now be passed as an array instead of an object:

// before

-modules: {
-  custom: {
-    resolve: "./modules/custom",
-      options: {
-      apiKey: "test",
-    },
-  },
-},
+modules: [
+ {
+    resolve:  "./modules/custom",
+    options: {
+      apiKey: "test",
+    },
+  },
+],

This is a backward-compatible change. The backward compatibility will be removed in the near future, so we recommend updating your medusa-config.js now.

With this change, we now default to using the key specificed in the module export to register the module in the dependency container.

For example, let's say you've built a custom module with the following export:

export default Module("my_custom_module", { ... } )

The registration key in the dependency container will be my_custom_module and is resolved as follows:

const service = req.scope.resolve("my_custom_module")

Breaking changes:

  • The import location changed for the following utils:
- import { MODULE_PACKAGE_NAMES } from "@medusajs/framework/modules-sdk
+ import { MODULE_PACKAGE_NAMES } from "@medusajs/framework/utils
  • The module registration key names have changed to be snake_cased instead of PascalCased:
- export const Modules = {
-   AUTH: "Auth",
-   CACHE: "Cache",
-   CART: "Cart",
-   CUSTOMER: "Customer",
-   EVENT_BUS: "EventBus",
...
- } as const
+ export const Modules = {
+   AUTH: "auth",
+   CACHE: "cache",
+   CART: "cart",
+   CUSTOMER: "customer",
+   EVENT_BUS: "event_bus",
...

The latter is only a breaking change if you have used raw strings to resolve modules from the dependency container.

Features

Bugs

Documentation

Read more

Medusa v2.0 Release Candidate #2

03 Oct 15:40
a461e21
Compare
Choose a tag to compare

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

  • feat(orchestration): Provide hint in workflows error by @adrien2p in #9400
  • feat(framework,medusa): Ensure publishable key middleware is set for all store endpoints by @riqwan in #9429
  • breaking: move shared HTTP utils to the framework by @thetutlage in #9402
  • feature: allow using typescript path aliases when using ts-node by @thetutlage in #9443

Bugs

Documentation

Chores

  • chore(types, utils): update the TSDocs of AbstractFulfillmentProviderService by @shahednasser in #9349
  • chore: Processing filters deeply looking at the current joiner first by @adrien2p in #9428
  • chore: improve mikro orm serializer circular ref and link serialization by @adrien2p in #9411
  • chore: add action to update starter dependencies + update reference actions by @shahednasser in #9385

Other Changes

  • feature: Add MikroORM CLI wrapper to bypass hardcoded module system by @thetutlage in #9426

New Contributors

Full Changelog: v2.0.0-rc...v2.0.0-rc.2

Medusa v2.0 Release Candidate #1

01 Oct 09:04
2094390
Compare
Choose a tag to compare

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

Read more

Preview Release Update #10

18 Sep 08:19
56ee4d6
Compare
Choose a tag to compare

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

  • docs: Rename remoteQuery to query and add db instrumentation flag by @thetutlage in #9159

Full Changelog: v2.0.9-preview...v2.0.10

Preview Release Update #9

16 Sep 12:28
8829f89
Compare
Choose a tag to compare

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 #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

  • feat(create-medusa-app): add publishable API key environment variable to Next.js storefront by @shahednasser in #9029
  • feat: Application types generation from project GQL schema's by @adrien2p in #8995
  • feat: Reset password by @olivermrbl in #8962
  • feat: Add support for refreshing JWT tokens by @sradevski in #9013
  • feature: introduce types for query.graph method by @thetutlage in #9031
  • feat: Add support for fetch streaming to js SDK by @sradevski in #9065
  • fix(utils,medusa,order,cart): fix totals when promotions are included by @riqwan in #9014
  • feat(payment): Payment providers are upserted upon loading by @riqwan in #9090
  • feat(dashboard) modal search autofocus by @fPolic in #9038
  • feat(utils,types,framework,medusa): store endpoints should require publishable key by @riqwan in #9068
  • feat(core-flows): product type, option and tag events by @carlos-r-l-rodrigues in #9105
  • feat(core-flows,dashboard,types,medusa): delete shipping methods when all inbound/outbound items are deleted by @riqwan in #9106
  • feat(core-flows,types,medusa): validate deleting location level when quantities exist by @riqwan in #9086
  • feat: introduce a thin wrapper on top of OpenTelemetry by @thetutlage in #9109
  • feat(api-key,js-sdk,dashboard): allow deleting api keys only once its revoked by @riqwan in #9118
  • feature: add telemetry to the HTTP layer by @thetutlage in #9116
  • feature: add tracing to remote query by @thetutlage in #9128
  • feat(core-flows,medusa,utils,types): adds delivered_quantity to order by @riqwan in #9130

Bugs

Documentation

Read more

v1.20.10

16 Sep 12:14
Compare
Choose a tag to compare

Bugs

Documentation

Full Changelog: 1.20.10...v1.20.11

Preview Release Update #8

06 Sep 08:34
abe7b66
Compare
Choose a tag to compare

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 #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

  • feat(dashboard,types): split damaged activity from received by @riqwan in #8859
  • feat(medusa): order changes endpoint by @carlos-r-l-rodrigues in #8728
  • feat(dashboard): order edits in timeline by @fPolic in #8899
  • feat(notification): Handle long running transaction and add status support by @adrien2p in #8900
  • feat(dashboard): allow custom shopping prices for claims/exchanges by @fPolic in #8912
  • feat(core-flows,types): Refunds can only be performed when order is imbalanced by @riqwan in #8944
  • chore(medusa): remove promotions in campaign validators + move tests to http by @riqwan in #8965
  • feat(dashboard): Cancel claims and exchanges by @fPolic in #8958
  • feat(dashboard): update create fulfillment UI part 1 by @fPolic in #8972
  • feat(utils): dml to graphql by @carlos-r-l-rodrigues in #8951
  • feat: Add github authentication provider by @sradevski in #8980
  • feat: added totals tests for end 2 end RMA flow by @riqwan in #8906
  • feat(types,medusa): add acknowledgement typing by @shahednasser in #8991
  • feat(admin-sdk,admin-bundler,admin-shared,medusa): Restructure admin packages by @kasperkristensen in #8988
  • feat(core-flows): custom price flag for order line items and shipping methods by @carlos-r-l-rodrigues in #8969
  • feat(core-flows,types,promotion): register promotion campaign usage upon cart completion by @riqwan in #8970
  • feat(product): product option value methods by @carlos-r-l-rodrigues in #9004
  • feat(dashboard, user): prefill invite email by @fPolic in #9016
  • feat(dashboard): add inventory kit info in order summary by @fPolic in #8990

Bugs

Documentation

Read more

Preview Release Update #7

29 Aug 09:43
ddddd43
Compare
Choose a tag to compare

Highlights

Bulk Editor improvements

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

error-bulk-editor.mp4

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

  • chore(medusa): Re enable plugin loading by @adrien2p in #8843
  • chore: Treat internal event differently, primarely do not display info logs for those events by @adrien2p in #8767
  • chore: Remove unused clients in admin + clean up js-sdk by @olivermrbl in #8839

Full Changelog: v2.0.6-preview...v2.0.7-preview

v2.0.6-preview

27 Aug 14:40
ac18b5d
Compare
Choose a tag to compare

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

  • feat(dashboard): Hitting escape restores previous value by @kasperkristensen in #8654
  • feat(workflows-sdk): log on error by @carlos-r-l-rodrigues in #8666
  • feat(dashboard,core-flows,js-sdk,types,link-modules,payment): ability to copy payment link by @riqwan in #8630
  • feat(dashboard): Wrap each route in an ErrorBoundary by @kasperkristensen in #8674
  • feat(core-flows): create or update payment collections in RMA flows by @riqwan in #8676
  • feat(dashboard,core-flows,js-sdk,types): ability to mark payment as paid by @riqwan in #8679
  • feat(dashboard,core-flows): ability to refund payment post RMA flow by @riqwan in #8685
  • fix(core-flows): account for unfulfilled items while generating order status by @riqwan in #8698
  • feat(dashboard): add activities for order - claim, exchange, payment by @riqwan in #8702
  • feat(core-flows): order edit request by @carlos-r-l-rodrigues in #8705
  • chore(order): align mikroorm <> order module by @riqwan in #8710
  • feat(fulfillment,order): add created_by fields to fulfillment, return, claim, exchange by @riqwan in #8711
  • feat(medusa,types,core-flows): apply created_by values - claims, exchanges, returns, fulfillment by @riqwan in #8712
  • feat: add missing crud to provider identity service by @christiananese in #8717
  • feat(utils): use dotenv-expand to allow variables within env by @shahednasser in #8720
  • feat(dashboard): order edit UI by @fPolic in #8700
  • feat(core-flows,dashboard): adds item validations for claims, returns and exchanges by @riqwan in #8735
  • feat(create-medusa-app): set database name to project name by @shahednasser in #8727
  • feat(dashboard,types): add active order change panel - claims, exchanges & returns by @riqwan in #8738
  • feat: add env editor utility to edit update .env files by @thetutlage in #8741
  • feature: add db:create command by @thetutlage in #8760
  • fix(dashboard): summary section return fixes by @fPolic in #8770
  • feat: add sync links command by @thetutlage in #8775
  • feat: move migrations commands to the new db namespace by @thetutlage in #8810
  • feat: create auth provider identity by @christiananese in #8675
  • feat: Separate registration from authentication in auth domain by @olivermrbl in #8683
  • feat(dashboard): cancel return request by @fPolic in #8761

Bugs

Documentation

Read more