**What**
- Initiate the framework package (which is just a place to move things around for now)
- move the config loader and related resources as well as the `ConfigModule` type
- Create a ConfigManager singleton which prepare and store the config (later can be stored entirely in the container) and allow for easier test override
- re export the logger from the framework
- replace medusa config loader with the framework one
- `build` run type check on tests as well but `prepublishOnly` will not fail on build if tests are typed broken
FIXES FRMW-2607
FIXES FRMW-2609
FIXES FRMW-2614
FIXES FRMW-2618
what:
- runs module and api integration tests in matrix strategy
- v28 of jest comes with sharding support, which we can utilize when we upgrade
- splits the tests by number of matrix jobs and run them in parallel
- This introduced some flakiness in some specs, but couldn't reproduce locally. Those have been skipped for now.
- uses swc/jest for added performance
- Locally, a chunk took 90 seconds with babel and 30 seconds with swc.
- This translated to 2 mins saved per shard in CI, but haven't tested this enough.
Few things to keep in mind:
1. You need to set MEDUSA_FF_MEDUSA_V2 to true before running the tests to run with the v2 API
2. You can use the `breaking` function to differentiate between v1 and v2 differences. This can help us identify what was breaking pretty quickly afterwards
3. You will need to run specific tests for now instead of all if you want to target v2. I think that's fine though, as we don't really need these to run on every PR until we have feature parity (and by then, all tests would be both v1 and v2 compatible)
**note: Adrien**
- add a new way to load modules only to run their loaders comparable to the way to run the migrations only
- improve tests runner to cleanup the data properly as well as re running all loaders and core defaults
Co-authored-by: Adrien de Peretti <25098370+adrien2p@users.noreply.github.com>
What:
Workflow Engine API.
Endpoints for:
- List workflow executions
- Run a workflow
- Set async steps as success or failure
- Retrieve the details of a workflow run
**What**
Integration tests to validate the workflow compensation.
Also, fix the transaction state when the workflow is compensating and some steps does not have any compensation
* 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
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
* 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>
