RESOLVES FRMW-2875
**What**
Allow to generate migration for plugins. Migration generation defer from project migration generation and therefore we choose to separate responsibility entirely.
The flow is fairly simple, the user run `npx medusa plugin:db:generate` and the script will scan for all available modules in the plugins, gather their models information and generate the appropriate migrations and snapshot (for later generation)
Co-authored-by: Harminder Virk <1706381+thetutlage@users.noreply.github.com>
what:
- adds a status column to promotion table
- introduce active promotion query
- scope revert, register and compute actions to active promotions
- admin to create and update promotion with statuses
RESOLVES CMRC-845
RESOLVES CMRC-846
RESOLVES CMRC-847
RESOLVES CMRC-848
RESOLVES CMRC-849
RESOLVES CMRC-850
RESOLVES FRMW-2862
**What**
This PR enable the `create-medusa-app` CLI to accept a new `--plugin` option to scaffold a plugin. This is complementary to all the plugin commands being created/adjusted separately to that pr.
Also, this pr brings a little refactoring around resource scaffolding, the idea was to contain the refactoring to a little area and not expend it to the entire create-medusa-app package to not disrupt and expand the scope for which the purpose was to introduce the plugin scaffolding capabilities
**Addition**
- medusa project will get their package.json name changed to the project name
- Remove build step from medusa project creation
**Plugin flow**
- in the plugin
- `npx create-medsa-app --plugin`
- `yarn dev`
- in the project
- `yalc add plugin-name`
- `yarn dev`
Any changes on the plugin will publish, push in the local registry which will fire the hot reload of the app and include the new changes from the plugin
Fixes: FRMW-2863
Adds the `plugin:build` command that is used to compile the source code of a plugin for publishing it to a package registry. The command is similar to the `build` command, except it does not copy the `package.json` and the `lock` files to the build output
Fixes: FRMW-2865
In this PR we add support for developing a plugin in watch mode. During the file change, we re-compile the source code (incrementally), publishes the package, and updates the installations of the plugin.
We are using `yalc` under the hood and it must be installed as a dev dependency in the plugin project and the main Medusa app.
Should not be merged before https://github.com/medusajs/medusa/pull/10895
**What**
- Introduces a new `plugin` command to `admin-bundler`, currently not used anywhere but will be called from `medusa build:plugin`
- Discovers plugins with extensions and add passes the to `admin-vite-plugin`.
- Updates `admin-vite-plugin` so its able to read built admin extensions.
Resolves CMRC-830, CMRC-839
Fixes: FRMW-2858
This PR merge the modules exported by the plugins with the modules defined within the user config. As a result, all modules get loaded without changing the internals of the loader.
However, you cannot disable the module of a plugin by re-adding it to the `modules` array. That is something we should handle separately.
We've added the breaking change label because of the following fix:
We did broke the ability to completely disable modules in the past pr's, in this pr we re add the ability to disable a module and that this modules does not get loaded at all. ([here](6dd164f783))
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
The `createProductsWorkflow` allows passing an `inventory_items` property to assign the inventory items of a product variant, and we even pass it in the `/admin/products` API route when creating a variant, but the workflow's input type doesn't include that property. This PR adds it to the workflow's input type.
RESOLVES FRMW-2835
In this PR, we trace HTTP requests using the route pattern and not the request URL. This allows us to aggregate all HTTP requests under a single route.
In terms of implementation, we have to self find the route for a given request, since there is no API in express to do the same and we begin tracing even before the request is handed over to Express.
Since, the route matching happens via RegExp matches, we ensure that this does not add much performance overhead. The matching takes between 0.8ms-1.5ms for various different routes
Co-authored-by: Harminder Virk <1706381+thetutlage@users.noreply.github.com>
FIXES FRMW-2852
**What**
A workflow distributed transaction expect any response and error to be serializable. When it is not the case, the distributed transaction might fail during the save checkpoint that occurs for async steps. This can lead to unexpected behaviour.
With this pr, we introduce a way to handle non serialazable object in a more sustainable manner, this means the following:
- If a workflow throw any non serialazable error (e.g AWS error that contains full IncomingMessage object that related to network communication, think of req/res) then we identify that this object is not serialzable and we clean up the object to make it serializable without loosing the main information, add a new error to the workflow to informed of this issue and can be handled by the user.
- If a response is not serializable (which should not happen at this point because it is handled before by the value resolver), in that case, we wont be able to reuse that response to continue the workflow which means that the workflow is in a non runnable state. In that case we throw a specific error stating that a non serializable context is being provided
**second what**
This pr refactor the `runAsStep` to add better support for workflow cancelation, especially async ones
