### What
Explicitly declare `@medusajs/medusa` as a devDependency for `@medusajs/medusa-js` client package.
### Why
With our latest version upgrade of `turbo`, peerDependencies aren't taken into account in the build graph. The recommendation is to also explicitly declare them in devDependencies.
### Test
* Run `yarn build --graph`
* Expect to see medusa-js having a dependency on medusa
```
"[root] @medusajs/medusa-js#build" -> "[root] @medusajs/medusa#build"
```
**What**
When a discount is deleted from a cart, the line item adjustments must be refreshed. Now, the cart service `removeDiscount` includes updating the adjustments.
**Tests**
**Add a new integration test which:**
- create a cart with a discount
- add a line item
- validate the adjustments
- remove the discount
- check that the adjustments are not present anymore
**Update unit tests**
The actual tests cases now check that the adjustments repository is called when needed
FIXES CORE-890
### What
Leverage yarn workspaces and Turborepo for integration-tests in order to accelerate development and reduce DevX complexity.
### Why
The current solution for running integration tests requires using `medusa-dev-cli` in order to publish packages to a local npm repository. The package where the command is executed will have its package.json altered for any known medusa dependency in order to install from the local npm. The process is taxing on the host machine resources and prevents rapid iterations when working with integration tests.
For more information, see documentation: https://github.com/medusajs/medusa/blob/f0cc1b324c964680c26e0d5c1d45769cbd750176/docs/content/usage/local-development.md#run-api-integration-tests
### How
By declaring `integeration-tests/**/*` as a workspace, Turborepo can now be leveraged to build and run integration test as if there were packages. The build process will take care of interdependency between package in order to ensure local dependency are met.
In addition, within each integration-tests "packages", we can declare local dependencies as "*" which will translate to using the one that is part of the current build, regardless of the dependency's version number. No more fiddling with version numbers.
Github actions pertaining to integration-tests have been streamlined to use the new behavior.
The integration-tests packages have been marked as `private:true` in order to avoid publishing them to the public npm registry.
### Testing
```
cd root-of-medusajs-medusa-repo/
yarn install
yarn build
yarn test:integration:api
yarn test:integration:plugins
```
After a code change, `yarn build` must be run before re-running an integration test, which is the same procedure as for unit tests.
Resolves: CORE-845
**What**
I have created a new method on the cart service which is `addLineItems`, allowing a user to add one or multiple items in an optimized way. Also updated the `generate` method from the line item service which now also accept a object data or a collection of data which. Various places have been optimized and cache support has been added to the price selection strategy.
The overall optimization allows to reach another 9000% improvement in the response time as a median (Creating a cart with 6 items):
| | Min (ms) | Median (ms) | Max (ms) | Median Improvement (%)
|---|:-:|---|---|---|
| Before optimisation | 1200 | 9999 | 12698 | N/A
| After optimisation | 63 | 252 | 500 | 39x
| After re optimisation | 56 | 82 | 399 | 121x
| After including addressed feedback | 65 | 202 | 495 | 49x
FIXES CORE-722
### What
OAS: Explicitly declare type:object on schemas with properties.
### Why
While not officially required, schemas with properties should have their type explicitly declared as "object". Omitting the type translates to type: any with properties XYZ. The ambiguity can lead to issues when using code generators.
### How
Multiple regex searches to identify schemas missing type: object. Manually edit each schema. Spot check generated OAS.
### Testing
- Ran OAS validator.
- Ran docs build script
### Proof

RESOLVES CORE-847
**What**
Allow DraftOrders to be created with an IdempotencyKey.
Note this doesn't implement idempotency for the DraftOrder create endpoint but allows the service layer to ingest the key and store it in the database. This is a preliminary step to being able to support an idempotent API request.
* use correct authentication middleware
* remove guard from get-session since it's guarded by middleware doing the same check
* Add integration tests
* Create lazy-swans-agree.md
Co-authored-by: olivermrbl <oliver@mrbltech.com>
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
**What**
Fix system error (500) with DraftOrder create operation when payload includes discount in a tax-inclusive context.
**How**
* Ensure newly created cart contains all required relation in order to calculate line item tax-inclusive pricing with discounts.
* Add resilience to TotalsService.getLineDiscounts()
* Ensure newly generate line items have variant relation loaded.
* fix TotalsService.getLineItemTotals to use the passed lineItem instead of relying on cartOrOrder.items.
**Test**
* Unit:
* TotalsService.getLineDiscounts - coverage
* Integration:
* Admin API draft-order - coverage
* Admin API draft-order create w/ discount in tax-inclusive
Resolves: CORE-771
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
**What**
BP plugin was recording total shipping price based on the shipping_method.price; however, this value may be with or without taxes depending on the tax inclusivity setting. This change ensures that the shipping price is calculated correctly.
**What**
- add error handling when loading project config
**How**
- Add error parameter to get-medusa-config result if an error was thrown (previously we returned an empty config)
- Discussion:
A different, but equally valid approach could be just throwing the error rather than creating an error parameter. This causes a more ugly output without warnings and changes the api a bit but it would force error handling. wdyt?
**Why**
- cli would fail with database error `databaseMissingDriverError` if config was invalid, ex. missing a comma
### example (missing `,` in config)
**old output**
```
Successfully compiled 2 files with Babel (143ms).
[medusa-config] ⚠️ redis_url not found. A fake redis instance will be used.
[medusa-config] ⚠️ database_type not found. fallback to default sqlite.
info: Using flag MEDUSA_FF_ORDER_EDITING from environment with value true
info: Using flag MEDUSA_FF_SALES_CHANNELS from environment with value true
info: Using flag MEDUSA_FF_TAX_INCLUSIVE_PRICING from environment with value true
info: Using fake Redis
✔ Models initialized – 13ms
✔ Plugin models initialized – 0ms
✔ Repositories initialized – 17ms
⠋ Initializing databaseMissingDriverError: Wrong driver: "undefined" given. Supported drivers are: "aurora-data-api", "aurora-data-api-pg", "better-sqlite3", "capacitor", "cockroachdb", "cordova", "expo", "mariadb", "mongodb", "mssql", "mysql", "nativescript", "oracle", "postgres", "react-native", "sap", "sqlite", "sqljs".
```
**new output**
```
Successfully compiled 2 files with Babel (185ms).
error: Error in loading config: Unexpected identifier
error: /Users/phko/projects/community/my-medusa-store/medusa-config.js:129
plugins,
^^^^^^^
SyntaxError: Unexpected identifier
at compileFunction (<anonymous>)
at Object.compileFunction (node:vm:352:18)
at wrapSafe (node:internal/modules/cjs/loader:1033:15)
at Module._compile (node:internal/modules/cjs/loader:1069:27)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at getConfigFile (/Users/phko/projects/community/my-medusa-store/node_modules/medusa-core-utils/dist/get-config-file.js:26:20)
```