**What**
- Move packages for `next` version of admin to core repo
**Other**
- Since this PR introduces packages that depend on Vite 5, it also introduces @types/node@^20. We have never had a direct dependency on the types package for Node, and as far as I can see that has resulted in us using the types from Node.js@8, as those are a dependency of one of our dependencies. With the introduction of @types/node@^20, two of our packages had TS errors because they were using the NodeJS.Timer type, which was deprecated in Node.js@14. We should add specific @types/node packages to all our packages, but I haven't done so in this PR to keep it as clean as possible.
- Q: @olivermrbl I've added the new packages to the ignore list for changeset, is this enough to prevent them from being published?
**What**
- Bumps `class-variance-authority` to new beta version - `cva@beta`.
- Updates all usages of `cva` to new API.
- Clear up the naming of types in `usePrompt`
**Why**
- A bug in how `class-variance-authority` exported its types mean that we were relying on patching the package to ensure that the correct types made it into the build of our UI package. This was important to ensure intellisense for component variants, such as `<Button size="large" />`. Previously in the UI monorepo, having the patch was enough to ensure that the correct types made it into the build, but that was not the case after we moved the design system to the core repo. The issue with types is fixed in the `@1` version of `cva` which is currently in beta. I have pinpointed the version to the current beta version to ensure stability despite the package currently being in beta.
* Feat: create product with product module
* feat: create product wip
* feat: create product wip
* feat: update product relation and generate image migration
* lint
* conitnue implementation
* continue implementation and add integration tests for produceService.create
* Add integration tests for product creation at the module level for the complete flow
* only use persist since write operations are always wrapped in a transaction which will be committed and flushed
* simplify the transaction wrapper to make future changes easier
* feat: move some utils to the utils package to simplify its usage
* tests: fix unit tests
* feat: create variants along side the product
* Add more integration tests an update migrations
* chore: Update actions workflow to include packages integration tests
* small types and utils cleanup
* chore: Add support for database debug option
* chore: Add missing types in package.json from types and util, validate that all the models are sync with medusa
* expose retrieve method
* fix types issues
* fix unit tests and move integration tests workflow with the plugins integration tests
* chore: remove migration function export from the definition to prevent them to be ran by the medusa cli just in case
* fix package.json script
* chore: workflows
* feat: start creating the create product workflow
* feat: add empty step for prices and sales channel
* tests: update scripts and action envs
* fix imports
* feat: Add proper soft deleted support + add product deletion service public api
* chore: update migrations
* chore: update migrations
* chore: update todo
* feat: Add product deletion to the create-product workflow as compensation
* chore: cleanup product utils
* feat: Add support for cascade soft-remove
* feat: refactor repository to take into account withDeleted
* fix integration tests
* Add support for force delete -> delete, cleanup repositories and improvements
* Add support for restoring a product and add integration tests
* cleaup + tests
* types
* fix integration tests
* remove unnecessary comments
* move specific mikro orm usage to the DAL
* Cleanup workflow functions
* Make deleted_at optional at the property level and add url index for the images
* address feedback + cleanup
* fix export
* merge migrations into one
* feat(product, types): added missing product variant methods (#4475)
* chore: added missing product variant methods
* chore: address PR feedback
* chore: catch undefined case for retrieve + specs for variant service
* chore: align TEntity + add changeset
* chore: revert changeset, TEntity to ProductVariant
* chore: write tests for pagination, unskip the test
* Create chilled-mice-deliver.md
* update integration fixtuers
* update pipeline node version
* rename github action
* fix pipeline
* feat(medusa, types): added missing category tests and service methods (#4499)
* chore: added missing category tests and service methods
* chore: added type changes to module service
* chore: address pr feedback
* update repositories manager usage and serialisation from the write public API
* move serializisation to the DAL
* rename template args
* chore: added collection methods for module and collection service (#4505)
* chore: added collection methods for module and collection service
* Create fresh-islands-teach.md
* chore: move retrieve entity to utils package
* chore: make products optional in DTO type
---------
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
* feat(product): Apply transaction decorators to the services (#4512)
---------
Co-authored-by: Riqwan Thamir <rmthamir@gmail.com>
Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
Co-authored-by: Carlos R. L. Rodrigues <37986729+carlos-r-l-rodrigues@users.noreply.github.com>
* chore: Use caret for all Medusa deps
* Create wild-balloons-push.md
* Address PR feedback
* force build order
* add missing dep
* add missing dev deps
* addresses last comments
## What
Harmonize and clean-up yarn test commands convention.
## Why
Current strategy to filter integration tests from unit tests was cumbersome to maintain. Also, some packages declared `test:unit` which ended up being an alias to `test`.
## How
* Remove all occurrences of `test:unit`
* Rename all `test` commands under `/integration-tests/**/package.json` to `test:integration`
* In the root `package.json`, rewrite `test:integration` command to run `turbo run test:integration`
* In the root `package.json`, remove filtering on the `test` command
* Introduce a new `test:integration` task in the Turborepo config.
## What
Alter generated types base on `x-expanded-relations` OAS extension declared on schemaObjects.
## Why
Often, API endpoints will automatically expand a model relations by default. They can also decorate a model with calculated totals. In order to more accurately represent the API, we wish to alter the generated types based on the expanded relations information.
## How
- Follow the relation declaration signature as the backend controllers and the `expand` query param, i.e.: `items.variant.product`.
- Introduce a custom `x-expended-relations` OAS extension.
- Allow for organizing declared relations to help their maintenance.
- Use traversal algorithms in codegen to support deeply nested relationships.
- Use [type-fest](https://www.npmjs.com/package/type-fest)'s `Merge` and `SetRequired` to efficiently alter the types while enabling great intellisense for IDEs.
Extra scope:
* Added convenience yarn script to interact with the `medisa-oas` CLI within the monorepo.
## Test
Include in the PR are two implementations of the x-expanded-relations on OAS schema, a simple and a complex one.
### Step 1
* Run `yarn install`
* Run `yarn build`
* Run `yarn medusa-oas oas --type combined --out-dir ~/tmp/oas`
* Run `yarn medusa-oas client --type combined --component types --src-file ~/tmp/oas/combined.osa.json --out-dir ~/tmp/types`
* Open `~/tmp/types/models/StoreRegionsRes`
* Expect relations to be declared as required
### Step 2
* Open `~/tmp/types/models/StoreCartsRes`
* Expect relations to be declared as required
* Expect nested relations to have relations as required.
### Step 3 (optional)
* Open `~/tmp/types` in an intellisense capable IDE
* Within the `index.ts` file, attempt to declare a `const storeRegionRes: StoreRegionRes = {}`
* Expect IDE to highlight that `countries` is a required field of `StoreRegionRes`
## What
Generated client types package based on the API's OpenApi Spec.
## Why
This package aims at replacing the need to import types directly from the core `@medusajs/medusa` package which can lead to side effects like importing backend dependencies into the client's realm.
## How
* The package contains a script that is invoked during the build step.
* The script will use the `medusa-oas oas --type=combined` cli to generate a combined oas file.
* Then, `medusa-oas client --component=types` uses the oas file to generate the types based on the OAS schema definitions. The result is outputted into `/src/lib`
* `prettier` is run on the `/src/lib` directory to ensure that the generated code follows the monorepo coding style.
* Finally, with `"emitDeclarationOnly": true`, `tsc` compiles the src directory to only output types.
Until we update our CI pipeline, we will not commit the content `/src/lib`.
## Test
* Run `yarn install`
* Run `yarn build`
* Expect `packages/generated/client-types/dist/` to contain types generated from the OAS defined by `@medusajs/medusa`
## What
Introduce a CLI for extracting OAS from the core `medusa` package.
## Why
We need to decouple OAS tooling from documentation tooling in order to allow packages and external systems to leverage our OAS has a dependency.
## How
Introduce a new OAS workspace within packages in order to organize current and future OAS related package. Only 1 OAS package for now.
Introduce a new CLI only package to act as the main gateway for all upcoming OAS tooling. Only 1 command for now.
Update documentation tooling pertaining to OAS to use the CLI instead.
## Test
### Prerequisite
From the monorepo root:
* `yarn install`
* `yarn build`
### Documentation
#### Case - validation only - success
* Run `yarn openapi:generate --dry-run`
* Expect console output `🟢 Valid OAS` but no mention of `🔵 Exported OAS`
#### Case - validation only - invalid
* Introduce a bug by renaming `@schema Cart` to `@schema Kart` in [models/cart.ts](0adb0d9ff9/packages/medusa/src/models/cart.ts (L2))
* Run `yarn build` to update `@medusajs/medusa` package with the bug.
* Run `yarn openapi:generate --dry-run`
* Expect console output `🔴 Invalid OAS` with a stack trace of the issue.
#### Case - docs generation
* Run `yarn openapi:generate`
* Expect `docs/api/` directory to contain:
* `admin.oas.json` (raw OAS)
* `store.oas.json` (raw OAS)
* `admin.oas.yaml` (sanitized OAS)
* `store.oas.yaml` (sanitized OAS)
* `admin/` (updated redocly split output)
* `store/` (updated redocly split output)
### CLI
#### Case - crawl additional paths
* From a local medusa server (`medusa-starter-default`), add an `index.ts` file in `src/models/`
* In the `index.ts`, add dummy OAS JSDoc like `/** @schema Foobar */`
* From the root of the monorepo, run `yarn medusa-oas --type store --paths path-to-medusa-server/src`
* Expect a `store.oas.json` to be created at the root of the monorepo.
* The `store.oas.json` should contain an additional `Foobar` entry in `components.schemas`.
### What
Add OAS build step to patch known circular references that prevent Redocly from rendering the API documentation.
### Why
We've encountered crashing and loading issues with Redocly when the OAS contained circular references. We have been working around the limitation by omitting some known problematic $ref in our source OAS. We wish to move away from this strategy in order to always explicitly include $ref in our OAS.
### How
We are introducing a custom Redocly CLI plugin that will replace `$ref` by `type: object` base on a configurable set of instructions. These instructions can be modified in `docs-util/redocly/config.yaml`
We are adding a `redocly bundle` step in the current OAS build process in order to sanitize problematic circular references.
We updated the redocly-cli package version in order to ensure that plugins are supported.
### Test
We will use [Cart.payment](fd5c185159/packages/medusa/src/models/cart.ts (L72-L74)) to ensure that the new process is properly sanitizing.
* Run `yarn openapi:generate`
* Open `docs/api/store/components/schemas/Cart.yaml`
* Expect the `payment` property to have been sanitized to `type: object`
* Run `yarn redocly preview-docs docs/api/store/openapi.yaml --config=docs-util/redocly/config.yaml`
* Visit http://127.0.0.1:8080/#tag/Cart/operation/GetCartsCart
* In the response, expect cart.payment to not list the properties of the Payment schema.
**What:**
Introduces a new folder under which repository specs will be placed.
Why:
We don't currently have a good place to test ORM logic or custom queries against the database. The repository folder tests are a place for just exactly that.
How:
Creates an internal package similar to other integration tests - api and plugins.
CORE-965
### 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
* 5093b82f3a/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: f0cc1b324c/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
* fix: caching deps + add true parallelization to integration tests api
* fix: github action
* chore: upgrade to yarn berry (#1762)
* init migration
* remove: yarn.lock from all pkgs
* fix: build script in pkgs
* adjust yarn config
* fix: yarn.lock and yarnrc.yml
* fix: github actions
* fix: wrong type
* fix (medusa-react): use dts-cli instead of tsdx
* fix: yarn.lock
* fix: yarn v
* fix: prepare script
* add: comment on why we need to downgrade yarn before medusa-dev
* chore: move to Turborepo (#1763)
* increase number of parallel nodes
* fix (medusa-fulfillment-webshipper): build script
* fix: use new version of medusa-dev
* fix: rename cache-bootstrap to cache-deps
