**What**
Add `POST /admin/regions`
Add `POST /admin/regions/:id`
Add `DELETE /admin/regions/:id`
All are added for v2 using API Routes and workflows.
In follow-up PRs, I will add support for passing countries in update and create.
Update: First follow-up PR is #6372
> This is a proposal - not necessarily the end result - to kick off the discussion about the implementation of the new totals utilities
### What
Introduces a BigNumber class implementation, enabling us to work with high-precision numeric values.
**Scope**
- Introduce the BigNumber class
- Remain somewhat backward-compatible (in behavior)
- Establish a foundation for handling high-precision values in more complex scenarios
**Not in scope**
- The implementation will not address complex use cases. However, the concept introduced now should be open for extensibility, so this can be added later without major changes to the calculation logic
### How
There are significant changes to three areas in this PR:
- Schemas
- (De)-Serialization
- Totals calculations
**Schemas**
Domains that need high-precision values will have two DB columns for each value in the database: a standard numeric column and a raw value column.
The standard column is for basic operations like sorting and filtering in the database and is what should be publicly exposed in our API.
The raw value is initially used solely for precise calculations and is stored as a JSONB column. Keeping it as JSONB is flexible and will allow us to extend the concept in future iterations. As of now, the raw value will only require a single property `value`.
**(De)-Serialization**
We cast the raw JSONB value to a `BigNumberRawValue` when reading from the database.
We serialize the standard value to a `BigNumber` when reading from the database.
We use the standard numeric value to construct the raw value upon writing to the database.
For example, the unit price and raw unit price on line items will be inserted as follows:
```ts
@BeforeCreate()
onCreate() {
this.id = generateEntityId(this.id, "cali")
const asBigNumber = new BigNumber(this.raw_unit_price ?? this.unit_price)
this.unit_price = asBigNumber.numeric
this.raw_unit_price = asBigNumber.raw
}
```
**Totals calculations**
For totals calculations, we will use the [`bignumber.js`](https://github.com/MikeMcl/bignumber.js/) library. The library ships with a `BigNumber` class with arithmetic methods for precise calculations.
When we need to perform a calculation, we construct the BigNumber class from the library using the raw value from the database.
Let's have a look at an oversimplified example:
```ts
// create cart with line items
const [createdCart] = await service.create([
{
currency_code: "eur",
items: [
// li_1234
{
title: "test",
quantity: 2,
unit_price: 100,
},
// li_4321
{
title: "test",
quantity: 3,
// raw price creation
unit_price: 200,
},
],
},
])
```
```ts
// calculating line item totals
import BN from "bignumber.js"
const lineItem1 = await service.retrieveLineItem("li_1234")
const lineItem2 = await service.retrieveLineItem("li_4321")
const bnUnitPrice1 = new BN(lineItem1.unit_price.raw)
const bnUnitPrice2 = new BN(lineItem2.unit_price.raw)
const line1Total = bnUnitPrice1.multipliedBy(lineItem1.quantity)
const line2Total = bnUnitPrice2.multipliedBy(lineItem2.quantity)
const total = line1Total.plus(line2Total)
```
**A note on backward compatibility**
Our BigNumber implementation is built to support the existing behavior of numeric values in the database. So even though we serialize the value to a BigNumber, you will still be able to treat it as a standard number, as we've always done.
For example, the following works perfectly fine:
```ts
const lineItem = await service.createLineItem({
title: "test",
quantity: 2,
unit_price: 100,
})
console.log(lineItem.unit_price) // will print `100`
```
However, the type of `unit_price` will be `number | BigNumber`.
Duplicate of #6008, but I messed up my git history big time :'(
**What**
- CartService and CartRepository + tests
- AddressService and AddressRepository + tests
- CartModuleService skeleton. Full implementation + tests will be added in a separate PR
**What**
- Migrate Stripe plugin to use API Routes + Subscribers
- Change the behaviour of Stripe webhook
Instead of processing webhook events immediately, we fire an event to perform the work in the background. The primary reason for changing the webhook is that the previous implementation led to occasional conflicts due to a race condition between the client's and the webhook's request to complete a cart. Now, we emit an event with a configurable delay (defaults to 2s) to prevent this from happening
This approach was preferred over adding a timeout directly to the webhook execution, as it is generally best practice to respond to a webhook event immediately after receiving it.
* 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
* chore(workflows): Use default starter template in action
* Use postgres by default in new
* Add skip DB flag
* Create thirty-tomatoes-hug.md
* address PR comments
Oli Juhl
