**What**
Re integrate the transform query tests + missing features. It was originally mistekenly removed from one the team pr, also, I have adjusted the API and tests
**NOTE**
It does not include a full clean up of the typings and the backward compatibility remains for now
* feat(core-flows,types,utils,medusa): Update existing line items when adding the same variant to cart
* chore: split steps into 2 for add-to-cart
* chore: split steps into 2 for add-to-cart
* chore: iterate safely
* chore: parallelize upsert
As we're adding some actions to the starter, it doesn't make sense to keep them in the cloned projects with `create-medusa-app`. This PR removes the `.github` directory from the project after cloning it
**What**
- remove medusa-core-utils
- dispatch the utils where they belongs
- update usage
**NOTE**
I have been wondering if the graceful class should go into the utils package or medusa package, I ve put it in the medusa package as it seems to be the best place I can see for now and is tight to the server as well. Also, I wanted to avoid the utils package to depends on http and net dependencies, happy to change that if you feel like it
**What**
Currently when a workflow fail it will throw an error which contains the messages of all error thrown durring the workflow lifetime. Therefore, in our cases we are always preventing workflow to throw and grab the first error that we then re throw.
This pr eliminate that need by throwing back the first error among the error thrown by a workflow as it is the main case. In case someone need a special handling they can still set the option throwOnError to false and handle the error the way they need
what:
The true source of promotions applied are present in the adjustments, previously we had links as the source of truth, but some issues popped up when you're trying to delete a line item as it was holding onto stale promotion data.
For this to truly work properly in the current form, we would have to pass data from the deleted line item step to the refresh promotion step and mutate the links twice to get the correct promotions for a cart. Additionally, the final list of codes to apply, comes from computeAction, because some previously applied codes could no longer be valid. The combination of passing codes from adjustments to computeActions and the codes returned from the computedActions are how we can accurately calculate the right promotions to apply.
With this change, the promotions step always look at the latest line item adjustments of the cart, pass them to compute actions, pick the correct codes to apply from the compute actions and then mutate the links based on the final result. This way, we perform the correct calculations for a cart and have promotion links that are correct.
