Fix `node-gyp` error that occurs during installation when using NPM and 20+ versions of Node.js. The error results from the package `@stdlib/number-float64-base-normalize` which is a dependency of `@segment/analytics-next`. Installing v0.0.8 resolves the error.
More details in PR #6485
## Testing
To test out the fix:
1. In a Medusa backend, remove the installation of `@stdlib/number-float64-base-normalize` (if available) and add instead the following override:
```json
"overrides": {
"@medusajs/admin": {
"@medusajs/admin-ui": "2.1.14-snapshot-20240405070935"
}
}
```
2. Remove node_modules + any previous package-lock.json
3. Change to node v20+ and use npm to install dependencies -> no error occurs during installation.
Before we would swallow the error and return a generic error to the user. This will provide more information to the caller if it is one of the known errors.
**What**
- Better error handling and error message
- update deps management and dynamic import/require
- Pass a new flag to the modules loaders for the module loaders to be able to act depending on it. In that case, the module can determine what should be run or not. e.g in the workflow engine redis, when we are only partially loading the module, we do not want to set the Distributed transaction storage
The only thing remaining is modifying `upsertWithReplace` to handle many-to-many constraints correctly and not cascade updates to them. This is something that we should do separately though.
## What
Adds a `--verbose` option that shows the output of all underlying processes in real-time.
## Why
This is helpful for testing and debugging issues, especially issues that the community runs into. We can ask community members to pass the `--verbose` option and provide us with the outputted logs if they face problems.
## Caveats
When installing the Next.js starter then terminating the process, the main and child processes don't receive the abort signal as it seems to occur in the child process. This leads to the command continuing but then running into an error in the next step.
As this option is only used for debugging, I don't think it's a big issue.
## Testing
Run the `create-medusa-app` snapshot below with `--verbose` option. Or, change to the `packages/create-medusa-app` directory and run:
```bash
yarn dev --directory-path ~/some-dir --verbose
```
> The `--directory-path` option in this case is necessary as installing the medusa backend in the current `packages/create-medusa-app` directory leads to errors related to yarn workspaces.
**What**
- Add workflow + step for detaching sales channels from pub API keys
- Tweak linking error message to be more helpful
- Add `removeRemoteLink` step to delete API key workflow
* feat: Modify the abstract repository upsert method to handle subresources correctly
* fix: Preserve the upsertWithResponse order in the response, and return all the data
* fix: Create integration tests folder for mikro orm utils that run against the DB
* fix: Remove many-to-one creation and additional changes based on PR review
**What**
- Fixes tsconfig to ensure a declaration file is included in the build.
**Why**
- Ensure tsserver can understand things from medusa-test-utils
- Get rid of "Could not find a declaration file for module" warning in editors.
What
- Add link between API key and sales channels
- Add API route for batch adding sales channels to a publishable API key
- Clean up API key API routes responses
- Move API key test suite from `integration-tests/modules` to `integration-tests/api`
**What**
- Adds Create draft order form
- Updates draft order details page to also display "custom" items.
**Note**
- Currently, the form is missing a way to input a discount code. Need to rethink this a bit, as the we can't implement the design in Figma.
- The current design is missing a way to select from a customers existing shipping addresses, we should add that to keep the features we have today.
- This PR uses `useInfiniteQuery` which does not work on our staging (due to duplicate dependencies as a result of building straight from the monorepo), so you will need to test locally.
## What
Added a `--v2` option to the `create-medusa-app` command that clones the [feat/v2](https://github.com/medusajs/medusa-starter-default/pull/150) branch of the starter default and makes minor changes to the setup process.
## Why
This option is supposed to make it easier to test out internally a Medusa setup with all the commerce modules. The starter's branch installs and configures the modules + the V2 feature flag.
## Testing
To test it out, run the snapshot with the `--v2` option.
## Notes
- I couldn't install the new admin dashboard in the starter branch as it's not on NPM yet (at the time of writing this), so at the moment, this opens the current admin dashboard instead.
- When trying to create an invite using the CLI tool I get the error `Unable to resolve inviteService`. Not sure if we should also make changes to the CLI tool to allow creating an invite when V2 is enabled (I know now invites are creating within the User Module, so maybe when the V2 feature flag is enabled that should be resolved instead), but for now I just disabled running the create invite command as this is mainly for internal testing. Let me know what the suggested approach is here.
