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.
## 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
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
* 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
