Closes#13163
I have a few questions about expected behaviour, since this currently breaks some tests:
- Many tests use the productModule to create products, with default status == "draft", and use the addToCart workflow which now throws. Should I change all breaking tests to specify status == "published" whne creating the product? The alternative would be to check the status in the store API route before the workflow but 1. it would be an extra query and 2. the addToCart workflow is only used in the store currently, and even if it was to be used admin-side, it still doesn't make sense to add a draft product to cart
- After this PR an unpublished product would give the same error as a variant that doesn't exist. While imho this is correct, the thrown error (for both) is "Items do not have a price" which doesn't make much sense(i believe the workflows goes through with an empty variants list and then errors at the price check point). Should I throw a different error when a variant doesn't exists/isn't published?
---
> [!NOTE]
> Enforces that only variants from published products can be added to carts, adds status fetching, refines errors, and updates tests to use ProductStatus.PUBLISHED.
>
> - **Core Flows**:
> - addToCart: Validate variants exist and belong to `product.status = PUBLISHED`; throw clear `INVALID_DATA` when not found/unpublished.
> - Data fetching: Include `product.status` in `cart` and `order` variant field selections.
> - **Tests/Fixtures**:
> - Update integration tests to set `status: ProductStatus.PUBLISHED` when creating products and import `ProductStatus` where needed.
> - Add cases for unpublished products and non-existent variants producing the new error message.
>
> <sup>Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit ca72532e957964d2d8e6bcecbb0905054c677ded. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).</sup>
Currently the plugin:db:generate command panics if one of the modules doesn't define any data models. This makes it impossible to generate migrations if you have a mix of modules with and without data models.
I added a simple check to skip these modules when creating the migrations.
Steps to repro:
```
npx create-medusa-app --plugin
cd my-medusa-plugin
# create a module with an empty service and no data models
npx medusa db:plugin:generate
```
Full error:
```
info: Generating migrations...
info: Generating migrations for module postmarkModuleService...
info: ----------------------------------------------------------------------------
error: defineMikroOrmCliConfig failed with: entities is required
Error: defineMikroOrmCliConfig failed with: entities is required
at defineMikroOrmCliConfig (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/utils/src/modules-sdk/mikro-orm-cli-config-builder.ts:41:11)
at generateMigrations (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:124:26)
at main (/Users/leonardo/dev/medusa-plugin-postmark/node_modules/@medusajs/medusa/src/commands/plugin/db/generate.ts:49:11)
at processTicksAndRejections (node:internal/process/task_queues:105:5)
```
I didnt bother with writing an issue since I had the fix ready and it's very small, but lmk if I should in the future
cc @willbouch since you asked to be tagged if I opened this PR.
The /store/shipping-options is one of only 2 store endpoints to not allow custom `fields` to be passed(other one is /store/returns if you guys want to add it to the backlog). This PR fixes that so that custom linked models can also be retrieved.
Note: This fix reveals a bug in the next.js starter
https://github.com/medusajs/nextjs-starter-medusa/blob/eac359cc8d52f1d33d8712e18e4e0f38940afb3e/src/lib/data/fulfillment.ts#L23-L24
`fields` was previously ignored, now it errors since it tries to parse the misspelled "fulfllment"(the i is missing). It worked before since both fields are already defined by default inside the workflow. So the `fields` line is totally redundant and should be removed(ideally before merging this).
Maybe in the next release notes it should also warn users to remove it for those that already have a modified copy of the starter.
Leonardo BeniniandGitHub
