@spree/docs 0.1.300 → 0.1.302
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -94,11 +94,12 @@ spree build --yes # Skip confirmation prompts (for CI)
|
|
|
94
94
|
|
|
95
95
|
Upgrade your project to the latest Spree release in one go. It works for both kinds of project:
|
|
96
96
|
|
|
97
|
-
1. **Update the server**
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
97
|
+
1. **Update the server** — on a project that runs the prebuilt image, it pulls the latest Spree image. On an [ejected](#spree-eject) project, it updates the Spree gems with `bundle update`.
|
|
98
|
+
2. **Update the `@spree/*` packages** — `@spree/cli` in the project root, and the dashboard packages and Admin SDK in `apps/dashboard` and `apps/seller-dashboard`. Each package moves to the newest release its declared range in `package.json` allows, the same way `bundle update` respects your `Gemfile`. To move to a new major version, change the range in `package.json` first.
|
|
99
|
+
3. **Migrate the database** — on a prebuilt-image project, it recreates the containers and the migrations run as they start. On an ejected project, it applies pending migrations.
|
|
100
|
+
4. **Run data backfills** — the version-specific steps from the upgrade manifest that convert existing records. An ejected project's app is then restarted so it loads the new gems.
|
|
101
|
+
|
|
102
|
+
The packages are updated before the database steps, so a failed migration or backfill no longer stops them from moving to the newest release their ranges allow. Fix the cause and run `spree upgrade` again.
|
|
102
103
|
|
|
103
104
|
```bash
|
|
104
105
|
spree upgrade # Run every step, asking before each one
|
|
@@ -151,7 +151,7 @@ To update to the latest Spree version:
|
|
|
151
151
|
spree upgrade
|
|
152
152
|
```
|
|
153
153
|
|
|
154
|
-
This updates the server (the Docker image, or the Spree gems on an ejected project)
|
|
154
|
+
This updates the server (the Docker image, or the Spree gems on an ejected project) and the `@spree/*` packages of the project and its dashboard apps, then runs database migrations and data backfills. See [`spree upgrade`](../cli/quickstart.md#spree-upgrade) for details.
|
|
155
155
|
|
|
156
156
|
To pin a specific version, edit `SPREE_VERSION_TAG` in `.env`:
|
|
157
157
|
|
|
@@ -574,6 +574,10 @@ These had no caller left in Spree, so they are removed with no replacement shim.
|
|
|
574
574
|
| `Spree::Carts::Empty` and `cart_empty_service` | remove items through the Store API cart items endpoints, or delete the cart with `Spree.cart_destroy_service` |
|
|
575
575
|
| `Spree::Payments::Create` and `payment_create_service` | the Store API payments endpoint, `Spree::StoreCredits::Apply` or `Spree.gift_card_apply_workflow` |
|
|
576
576
|
|
|
577
|
+
### Products no longer touch their categories
|
|
578
|
+
|
|
579
|
+
Saving or touching a product used to bump the `updated_at` of each of its categories and their parents, through `Spree::Products::TouchCategoriesJob` (formerly `TouchTaxonsJob`). That kept the old Rails storefront's page caches fresh. The Store API doesn't need it: a category's response has no product data, and product responses are cached on the products' own timestamps. Both jobs are removed. If your own code caches product data under a category's `cache_key_with_version`, include the products' timestamps in that key instead. Jobs still queued from before the upgrade fail with an unknown class error and can be discarded.
|
|
580
|
+
|
|
577
581
|
### The Legacy order-routing strategy is gone
|
|
578
582
|
|
|
579
583
|
`Spree::OrderRouting::Strategy::Legacy` — the pre-5.5 escape hatch that delegated straight to `Spree::Stock::Coordinator` and consulted no routing rules — is removed and no longer registered in `Spree.order_routing.strategies`.
|
|
@@ -11,7 +11,7 @@ We strongly advise upgrading Spree incrementally, rather than in one big go.
|
|
|
11
11
|
|
|
12
12
|
## How to upgrade
|
|
13
13
|
|
|
14
|
-
An upgrade updates the server, migrates the database, runs the version's data backfills
|
|
14
|
+
An upgrade updates the server and the `@spree/*` packages of your dashboard apps, migrates the database, and runs the version's data backfills. Always read the guide for the version you're moving to first — it lists the behavior changes to review.
|
|
15
15
|
|
|
16
16
|
**Spree CLI:**
|
|
17
17
|
|
|
@@ -19,23 +19,23 @@ An upgrade updates the server, migrates the database, runs the version's data ba
|
|
|
19
19
|
spree upgrade
|
|
20
20
|
```
|
|
21
21
|
|
|
22
|
-
One command for every project: it pulls the new image, or updates the Spree gems on an [ejected](../cli/quickstart.md#spree-eject) project, then runs migrations
|
|
22
|
+
One command for every project: it pulls the new image, or updates the Spree gems on an [ejected](../cli/quickstart.md#spree-eject) project, then updates the packages and runs migrations and data backfills. See [`spree upgrade`](../cli/quickstart.md#spree-upgrade) for its options.
|
|
23
23
|
|
|
24
24
|
**Without CLI:**
|
|
25
25
|
|
|
26
26
|
Run from the project root:
|
|
27
27
|
|
|
28
28
|
```bash
|
|
29
|
-
cd server
|
|
30
|
-
bundle update $(bundle list --name-only | grep ^spree)
|
|
31
|
-
bin/rails spree:install:migrations db:migrate
|
|
32
|
-
bin/rails spree:upgrade
|
|
33
|
-
cd ..
|
|
29
|
+
(cd server && bundle update $(bundle list --name-only | grep ^spree))
|
|
34
30
|
|
|
35
31
|
# The project root and each dashboard app have their own package.json
|
|
36
32
|
pnpm update "@spree/*"
|
|
37
33
|
(cd apps/dashboard && pnpm update "@spree/*")
|
|
38
34
|
(cd apps/seller-dashboard && pnpm update "@spree/*")
|
|
35
|
+
|
|
36
|
+
cd server
|
|
37
|
+
bin/rails spree:install:migrations db:migrate
|
|
38
|
+
bin/rails spree:upgrade
|
|
39
39
|
```
|
|
40
40
|
|
|
41
41
|
On npm or Yarn, run `npm update` or `yarn upgrade` instead, naming each `@spree/*` package from that `package.json` (they do not accept the `"@spree/*"` pattern).
|