### What
Move inline OAS requestBody schema declaration under their respective class-validator classes in order to expose them through `#/components/schemas`. Replace inline OAS requestBody schema with a `$ref` reference pointing to the newly declared schema.
### Why
Having requestBody declared as its own "named" schema will allow OAS code generators to output typed entities/DTO that can be manipulate without having to reference the route/operation.
### How
Declare a new @schema JSDoc for each class-validator used to parse and validate request body. Move the current inline requestBody to the new @schema.
### Test
- Ran OAS validator.
- Ran docs build script.
Expect no visible changes to the documentation.
### Out-of-scope
requestBody of type `multipart/form-data` used for file uploads. These will be address as part of CORE-934
- [create-upload.ts](https://github.com/medusajs/medusa/blob/58d23a7b45b6dde8bdeed0bb268139a0017f1649/packages/medusa/src/api/routes/admin/uploads/create-upload.ts#L87-L90)
- [create-protected-upload.ts](https://github.com/medusajs/medusa/blob/58d23a7b45b6dde8bdeed0bb268139a0017f1649/packages/medusa/src/api/routes/admin/uploads/create-protected-upload.ts#L87-L90)
Path Parameter and Query Parameter. These will need more research and experimentation, part of CORE-931
---
Resolves CORE-853
### What
Rename all JSDoc OAS `@schema` and `$ref: #/components/schemas/` from snake_case to PascalCase, `foo_bar -> FooBar`
Extra scope: Remove `x-resourceId` from JSDoc OAS.
### Why
Classes use PascalCase as a convention but the OAS @schemas describing them were using snake_case. OAS code generators tend to use the schema name when generating typed models.
In order to avoid mismatch between source code, the OAS, and the generated client code, it is advised to align OAS @schemas formatting to the classes they represent.
Extra scope: x-resourceId is not a widely used OAS property. It's current usage in our OAS does not provide additional value. Therefore, we recommend to remove it in order to have one less item to maintain.
### How
Good old search & replace. Regex search to further make sure we didn't miss any.
The scope is limited to `@schema` definition and their usage in `$ref: #/components/schemas/`.
### Test
* Ran OAS validator.
* Ran docs build script.
Expect no visible changes to the documentation.
Resolves: CORE-852, CORE-859
### 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
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
Flip Turborepo cache glob pattern from an allow-list to deny-list pattern.
### Why
Packages within medusa's monorepo will output their build to a `dist` directory.
This convention does not apply to plugins since the core plugin loader expects the content of plugin packages `src` directory to be outputted at the root of the package.
i.e. `packages/foobar-plugin/src/utils/index.ts` -> `packages/foobar-plugin/utils/index.js`
Manually maintaining an allow-list of known plugin output directories is not scalable. When a directory exists in a plugin package but is not know to the allow-list, the directory will not be re-built on subsequent builds. Troubleshooting the issue requires intimate knowledge of Turborepo caching strategies.
### How
By using a deny-list glob pattern, plugin packages can now declare any not-known directory within their `src` folder without facing any potential omission issues during the build process.
We declare `src` and its content as the only directory for turbo cache to ignore.
### Additional scope
* Use `turbo.json` file content in cache hashing algorithm in order to break CI cache when changes are made to the Turborepo config.
* Upgraded turbo minor verion.
* Added missing dependency to medusa package.
### Test
* Delete previously built output in packages. Run `yarn build --force` (replace any existing cache)
* Expect all src content to be outputted
* Run `yarn build` right after
* Expect a fast build time since cache will be fresh
* Add a new directory with an index.ts file in a plugin package src folder. Run `yarn build`
* Expect a fast build time, except for the modified plugin package.
* Expect the newly added directory to be outputted.
* Delete the newly outputted directory. Run `yarn build`
* Expect the outputted directory to reappear.
### References
* https://github.com/medusajs/medusa/blob/5093b82f3a28323e99b6b133ae87c76fac01a298/packages/medusa/src/loaders/plugins.ts
* https://turbo.build/repo/docs/reference/configuration#outputs
* https://turbo.build/repo/docs/reference/configuration#globaldependencies
Resolves CORE-891
### 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
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**
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>
PatrickandGitHub
