@mercurjs/docs 2.2.0 → 2.2.1-canary.1

package/README.md

@@ -20,5 +20,6 @@ Paths in `llms.txt` are relative to this package
 
 ## Build
 
-`content/` and `llms.txt` are generated from `apps/docs/rc` by
+`content/` and `llms.txt` are generated from the root of `apps/docs`
+(archived versions such as `apps/docs/v1` are excluded) by
 `scripts/build.mjs` (run via `turbo run build`). They are not committed.

package/content/blocks.mdx

@@ -13,7 +13,7 @@ mode: "custom"
       Blocks are modular pieces of marketplace functionality — API routes, workflows, UI pages, and data models. Each block is copied directly into your project. You own the code.
     </p>
     <div className="inline-flex items-center gap-3 px-4 py-2.5 rounded-lg border border-gray-200 dark:border-gray-700 bg-gray-50 dark:bg-gray-800">
-      <code className="text-sm font-mono text-gray-800 dark:text-gray-100">bunx @mercurjs/cli@rc add &lt;block-name&gt;</code>
+      <code className="text-sm font-mono text-gray-800 dark:text-gray-100">bunx @mercurjs/cli@latest add &lt;block-name&gt;</code>
     </div>
   </div>
 
@@ -170,7 +170,7 @@ mode: "custom"
     <h3 className="text-lg font-semibold mb-2">Install a block</h3>
 
 ```bash
-bunx @mercurjs/cli@rc add reviews
+bunx @mercurjs/cli@latest add reviews
 ```
 
 This copies the block source code into your project:
@@ -195,13 +195,13 @@ src/
     <h3 className="text-lg font-semibold mt-6 mb-2">Search blocks</h3>
 
 ```bash
-bunx @mercurjs/cli@rc search -q "reviews"
+bunx @mercurjs/cli@latest search -q "reviews"
 ```
 
     <h3 className="text-lg font-semibold mt-6 mb-2">Compare local changes against registry</h3>
 
 ```bash
-bunx @mercurjs/cli@rc diff reviews
+bunx @mercurjs/cli@latest diff reviews
 ```
 
   </div>

package/content/learn/architecture.mdx

@@ -163,7 +163,7 @@ This means:
 - There are no hidden abstractions or version conflicts
 - Updates are explicit — you diff and apply changes from the registry
 
-The CLI (`@mercurjs/cli@rc`) manages this process: scaffolding projects, installing blocks, searching the registry, and comparing local changes against upstream versions.
+The CLI (`@mercurjs/cli@latest`) manages this process: scaffolding projects, installing blocks, searching the registry, and comparing local changes against upstream versions.
 
 ## Workflow example
 

package/content/learn/blocks.mdx

@@ -8,8 +8,8 @@ Blocks are the unit of distribution in Mercur. Each block is a self-contained fe
 ## Installing blocks
 
 ```bash
-bunx @mercurjs/cli@rc add reviews
-bunx @mercurjs/cli@rc add wishlist product-import-export
+bunx @mercurjs/cli@latest add reviews
+bunx @mercurjs/cli@latest add wishlist product-import-export
 ```
 
 The CLI fetches the block from the [registry](/rc/learn/registry), resolves dependencies, transforms imports to match your project's path aliases, and copies the files into the right directories.
@@ -65,20 +65,20 @@ After adding a block, the CLI shows setup instructions. Typically you need to:
 1. **Register the module** in `medusa-config.ts`
 2. **Add middlewares** to your `api/middlewares.ts`
 3. **Run migrations** with `bunx medusa db:generate` and `bunx medusa db:migrate`
-4. **Regenerate types** with `bunx @mercurjs/cli@rc codegen`
+4. **Regenerate types** with `bunx @mercurjs/cli@latest codegen`
 
 ## Updating blocks
 
 Check for changes against the registry:
 
 ```bash
-bunx @mercurjs/cli@rc diff reviews
+bunx @mercurjs/cli@latest diff reviews
 ```
 
 If there are updates you want, re-install with the overwrite flag:
 
 ```bash
-bunx @mercurjs/cli@rc add reviews --overwrite
+bunx @mercurjs/cli@latest add reviews --overwrite
 ```
 
 Since blocks are source code in your project, you control when and how updates are applied.
@@ -88,12 +88,12 @@ Since blocks are source code in your project, you control when and how updates a
 Search the registry to see what's available:
 
 ```bash
-bunx @mercurjs/cli@rc search
-bunx @mercurjs/cli@rc search --query wishlist
+bunx @mercurjs/cli@latest search
+bunx @mercurjs/cli@latest search --query wishlist
 ```
 
 View details about a specific block:
 
 ```bash
-bunx @mercurjs/cli@rc view reviews
+bunx @mercurjs/cli@latest view reviews
 ```

package/content/learn/concepts.mdx

@@ -73,7 +73,7 @@ A registry is a collection of blocks available for installation. The official Me
 
 ## CLI
 
-The [Mercur CLI](/rc/tools/cli) (`@mercurjs/cli@rc`) manages your project — scaffolding from templates, installing blocks, searching registries, generating types, and diffing local changes against upstream versions.
+The [Mercur CLI](/rc/tools/cli) (`@mercurjs/cli@latest`) manages your project — scaffolding from templates, installing blocks, searching registries, generating types, and diffing local changes against upstream versions.
 
 ## Dashboard SDK
 
@@ -81,4 +81,4 @@ The [Dashboard SDK](/rc/tools/dashboard-sdk) (`@mercurjs/dashboard-sdk`) is a Vi
 
 ## API Client
 
-The [API Client](/rc/tools/api-client) (`@mercurjs/client`) provides type-safe access to all Mercur API endpoints. Types are generated from your actual API routes using `bunx @mercurjs/cli@rc codegen`, so requests and responses are always in sync with your backend.
+The [API Client](/rc/tools/api-client) (`@mercurjs/client`) provides type-safe access to all Mercur API endpoints. Types are generated from your actual API routes using `bunx @mercurjs/cli@latest codegen`, so requests and responses are always in sync with your backend.

package/content/learn/installation.mdx

@@ -29,7 +29,7 @@ description: "Install Mercur and set up your marketplace project."
 ## Create a new project
 
 ```bash
-bun create mercur-app@rc
+bun create mercur-app@latest
 ```
 
 The CLI will prompt for a project name and template, then handle everything automatically:
@@ -88,7 +88,7 @@ bun dev
 If you have an existing Medusa project, initialize Mercur in it:
 
 ```bash
-bunx @mercurjs/cli@rc init
+bunx @mercurjs/cli@latest init
 ```
 
 This creates a `blocks.json` configuration file in your project.
@@ -98,13 +98,13 @@ This creates a `blocks.json` configuration file in your project.
 Install blocks from the registry:
 
 ```bash
-bunx @mercurjs/cli@rc add <block-name>
+bunx @mercurjs/cli@latest add <block-name>
 ```
 
 Browse available blocks:
 
 ```bash
-bunx @mercurjs/cli@rc search
+bunx @mercurjs/cli@latest search
 ```
 
 ## Run database migrations

package/content/learn/introduction.mdx

@@ -41,11 +41,11 @@ Most AI coding tools generate loose snippets that you have to wire together your
 
 Here's what that looks like in practice:
 
-- **Adding features via CLI** — An AI agent can run `bunx @mercurjs/cli@rc add reviews` to install a complete review system — data models, API routes, workflows, and UI — in one command. No guessing at file structure or imports. The CLI handles wiring automatically.
+- **Adding features via CLI** — An AI agent can run `bunx @mercurjs/cli@latest add reviews` to install a complete review system — data models, API routes, workflows, and UI — in one command. No guessing at file structure or imports. The CLI handles wiring automatically.
 - **Extending workflows without rebuilding them** — Need custom logic when an order is placed? AI can hook into the existing `complete-cart-with-split-orders` workflow and inject a step — without rewriting the entire cart flow. Medusa's workflow hooks make this safe and predictable.
-- **Generating typed integrations** — AI reads the generated route types from `bunx @mercurjs/cli@rc codegen` and produces API calls that are correct by construction. No hallucinated endpoints, no wrong payloads — the types are the source of truth.
+- **Generating typed integrations** — AI reads the generated route types from `bunx @mercurjs/cli@latest codegen` and produces API calls that are correct by construction. No hallucinated endpoints, no wrong payloads — the types are the source of truth.
 - **Building UI pages** — AI can scaffold an admin or vendor page by creating a file in `src/routes/`. The dashboard SDK picks it up automatically through file-based routing. No manual route registration, no config files to update.
-- **Modifying blocks it can diff** — AI can compare local code against the registry with `bunx @mercurjs/cli@rc diff`, understand what changed, and make targeted modifications instead of blind overwrites.
+- **Modifying blocks it can diff** — AI can compare local code against the registry with `bunx @mercurjs/cli@latest diff`, understand what changed, and make targeted modifications instead of blind overwrites.
 
 ### Connect your AI tools
 

package/content/learn/mirakl-alternative.mdx

@@ -0,0 +1,86 @@
+---
+title: "Mercur - an open-source Mirakl alternative"
+description: "How Mercur compares to Mirakl and other marketplace platforms: open-source, self-hosted, no GMV fees, full code ownership."
+---
+
+If you're evaluating [Mirakl](https://www.mirakl.com/) - or any hosted, enterprise marketplace SaaS - Mercur is the open-source alternative built for teams that want to own their marketplace outright instead of renting it.
+
+Mirakl is a mature, capable platform. It's also closed-source, priced as a percentage of the GMV that flows through it, and delivered as a hosted service you don't control. Mercur takes the opposite position: MIT-licensed core, self-hosted on your own infrastructure, no per-transaction cut, and full access to every line of code.
+
+This page is an honest comparison. Mirakl is the right choice for some teams; Mercur is the right choice for others. The goal here is to help you tell which one you are.
+
+## At a glance
+
+|                               | **Mercur**                                                                         | **Mirakl**                              |
+| ----------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------- |
+| **License**                   | Open source (MIT core)                                                             | Proprietary / closed source             |
+| **Hosting**                   | Self-host anywhere, or fully managed (Medusa Cloud / Rigby-hosted)                 | Vendor-hosted SaaS only                 |
+| **Pricing model**             | No GMV fees, no per-transaction cut                                                | Percentage of GMV + platform fees       |
+| **Code ownership**            | Full source access; fork or modify freely                                          | No source access                        |
+| **Customization**             | Extend/override workflows, APIs, and UI without forking                            | Configuration within platform limits    |
+| **Data ownership**            | Your database, your infrastructure                                                 | Vendor-controlled                       |
+| **Tech stack**                | TypeScript, Node.js, React, PostgreSQL                                             | Proprietary                             |
+| **Extensibility**             | Composable blocks, typed API client, workflow hooks, Dashboard SDK                 | Connectors and APIs within the platform |
+| **Storefront**                | Bring your own (headless, API-first)                                               | Integrated / connector-based            |
+| **Enterprise features**       | Mercur Enterprise: Buy Box, dedup, master-data governance, KYC - on your own infra | Included in the platform                |
+| **Support & SLAs**            | Contractual SLAs and named contact via Mercur Enterprise                           | Vendor support contract                 |
+| **Delivery help**             | Rigby builds/launches marketplaces with you                                        | Sales-led onboarding                    |
+| **Time to first marketplace** | `bun create mercur-app` in minutes                                                 | Sales-led onboarding                    |
+
+## Where Mercur is the better fit
+
+- **You want to own your marketplace, not rent it.** No percentage of GMV, no per-transaction cut, no vendor lock-in. Your data, customers, and roadmap stay yours.
+- **You have (or want) an engineering team.** Mercur is code you control end-to-end. If you plan to customize deeply - bespoke commission logic, custom vendor onboarding, non-standard order flows - an open, hackable core is a decisive advantage over a configuration-bound SaaS.
+- **You need to control where data lives.** Self-host on your own cloud, on-prem, or inside an air-gapped network. There's no proprietary runtime to adopt and no hosting tier you're forced onto.
+- **You want to avoid platform risk.** MIT license means the core can never be taken away from you, re-priced out from under you, or discontinued.
+
+## Enterprise-grade, without giving up ownership
+
+The features that usually pull teams toward Mirakl - a winning-offer engine, product deduplication, master-data governance, multi-channel stock sync, vendor KYC - aren't a reason to accept closed source and GMV fees. **[Mercur Enterprise](https://www.mercurjs.com/enterprise)** delivers that same enterprise surface area as a licensed module suite you deploy and run on your own infrastructure, exactly like the open-source core:
+
+- **Buy Box / winning-offer engine** - pick the winning offer across competing sellers, the way large marketplaces do.
+- **EAN matching & deduplication** - collapse duplicate seller submissions into a single master product.
+- **Master-data governance** - controlled, auditable catalog data across thousands of vendors.
+- **Multi-channel stock sync** - keep inventory consistent across sales channels and feeds.
+- **Automated split payouts & vendor KYC** - compliant onboarding and settlement at scale.
+
+…and more, with new modules added over time.
+
+Everything is maintained, tested, and upgraded by the core team, and backed by a direct support relationship: a dedicated support channel, contractual SLAs with guaranteed response times, prioritized bug fixes and security patches, and hands-on onboarding and architecture guidance. Higher tiers add priority escalation and a named technical contact.
+
+The difference from Mirakl: you still own the code, host it yourself, and pay no percentage of GMV.
+
+## Don't want to build it yourself? We'll build it with you
+
+Mercur is built and maintained by [Rigby](https://rigbyjs.com), a team that has designed, built, and launched multi-vendor marketplaces in production. If you'd rather not staff the whole project, we work alongside your team - architecture reviews, integrating Mercur with your existing stack, hardening, scaling, and getting your marketplace live on schedule.
+
+This closes the usual "we don't have engineering capacity" gap that sends teams to a fully managed SaaS: you get a done-with-you (or done-for-you) delivery path _and_ keep an open-source core you own. [Talk to our team](https://www.mercurjs.com/contact).
+
+### Don't want to run the infrastructure either?
+
+You don't have to. Not wanting to manage servers is not a reason to accept closed source and GMV fees - Mercur runs as a fully managed deployment too. Ship it to [Medusa Cloud](https://medusajs.com/pricing/) with push-to-deploy and auto-scaling, or have Rigby deploy, host, and operate it for you. Either way you get the zero-ops experience of a SaaS while keeping the open-source core, your data, and no percentage of GMV.
+
+## Migrating from Mirakl
+
+Already live on Mirakl? Rigby helps you move - porting your catalog, sellers, offers, orders, and commission structure onto Mercur, then hardening and cutting over without disrupting your marketplace. [Talk to our team](https://www.mercurjs.com/contact) to scope a migration.
+
+## What Mercur gives you
+
+Built on the [Medusa](https://medusajs.com) commerce framework, Mercur adds the marketplace layer on top:
+
+- **Multi-vendor sellers** - onboarding, approval, suspension, and member management.
+- **Master products & offers** - a shared catalog where multiple sellers list offers (SKU, price, inventory, shipping) against the same product.
+- **Commissions** - configurable fixed or percentage rules matching across product, type, collection, category, and seller.
+- **Automated vendor payouts** - a pluggable payout pipeline with Stripe Connect out of the box.
+- **Order splitting** - a single customer cart spanning multiple sellers splits into per-seller orders under an order group.
+- **Admin and Vendor panels** - role-specific dashboards, plus a headless Store API for any storefront.
+
+See [Concepts](/rc/learn/concepts) and [Architecture](/rc/learn/architecture) for the full picture, or jump straight to [Installation](/rc/learn/installation) to spin up a marketplace locally.
+
+## Get started
+
+```sh
+bun create mercur-app@latest my-marketplace
+```
+
+Then head to the [Installation guide](/rc/learn/installation) to run it locally, or [talk to our team](https://www.mercurjs.com/contact) if you're migrating from an existing platform.

package/content/learn/registry.mdx

@@ -7,7 +7,7 @@ A registry is a collection of blocks that can be installed into any Mercur proje
 
 ## How it works
 
-A registry is a set of JSON files — one per block — served over HTTP. When you run `bunx @mercurjs/cli@rc add`, the CLI fetches the block's JSON, resolves its dependencies, and copies the source files into your project.
+A registry is a set of JSON files — one per block — served over HTTP. When you run `bunx @mercurjs/cli@latest add`, the CLI fetches the block's JSON, resolves its dependencies, and copies the source files into your project.
 
 ```
 registry/
@@ -62,7 +62,7 @@ The `registry.json` file defines your registry and all its blocks:
 
 | Property               | Description                                                    |
 | ---------------------- | -------------------------------------------------------------- |
-| `name`                 | Block identifier used in `bunx @mercurjs/cli@rc add`               |
+| `name`                 | Block identifier used in `bunx @mercurjs/cli@latest add`               |
 | `description`          | Short description shown in search results                      |
 | `dependencies`         | NPM packages to install                                        |
 | `registryDependencies` | Other blocks this block depends on (e.g. `@mercurjs/wishlist`) |
@@ -91,7 +91,7 @@ These map to the aliases defined in the consumer's `blocks.json`.
 Build your registry into distributable JSON files:
 
 ```bash
-bunx @mercurjs/cli@rc build
+bunx @mercurjs/cli@latest build
 ```
 
 This reads `registry.json`, resolves all imports for each block, embeds the file contents, and outputs one JSON file per block to the `r/` directory.
@@ -122,7 +122,7 @@ Add your registry to `blocks.json` in any Mercur project:
 Use `{name}` as a placeholder for block names. Then install blocks from it:
 
 ```bash
-bunx @mercurjs/cli@rc add @my-org/reviews
+bunx @mercurjs/cli@latest add @my-org/reviews
 ```
 
 ### Authentication

package/content/migration/from-1-x-to-2-0.mdx

@@ -121,7 +121,7 @@ export const GET = async (
 ) => { ... }
 ```
 
-Run `bunx @mercurjs/cli@rc codegen` after adding routes.
+Run `bunx @mercurjs/cli@latest codegen` after adding routes.
 
 ### Links and Subscribers
 

package/content/resources/ai/overview.mdx

@@ -30,7 +30,7 @@ Because the docs travel with the package, an agent always has documentation that
 
 ### New projects
 
-Projects created with `bunx @mercurjs/cli@rc create` are ready out of the box. The template ships:
+Projects created with `bunx @mercurjs/cli@latest create` are ready out of the box. The template ships:
 
 - `@mercurjs/docs` as a dependency, so the docs land in `node_modules` on install
 - an `AGENTS.md` and a `CLAUDE.md` at the project root that tell agents to read the bundled docs first
@@ -79,7 +79,7 @@ Mercur gives an agent a fast, machine-checkable way to know whether a change is
 | `bun run build` | Types resolve and the generated client matches the routes |
 | `bun run lint` | Code conforms to the project's rules |
 | Integration tests (`packages/api`) | Backend behavior still holds |
-| `bunx @mercurjs/cli@rc diff` | Local blocks vs. the registry — what changed and what drifted |
+| `bunx @mercurjs/cli@latest diff` | Local blocks vs. the registry — what changed and what drifted |
 
 Because these are objective, an agent can define what "done" looks like, run the checks, read the output, and iterate until they pass — instead of stopping at "looks plausible."
 

package/content/resources/integrations/search.mdx

@@ -58,9 +58,9 @@ The bundled `search-orama` provider keeps the index in RAM inside the API proces
 Ready-made provider integrations ship as blocks:
 
 ```bash
-bunx @mercurjs/cli@rc add algolia
+bunx @mercurjs/cli@latest add algolia
 # or
-bunx @mercurjs/cli@rc add meilisearch
+bunx @mercurjs/cli@latest add meilisearch
 ```
 
 | Provider | Hosting | Best for |

package/content/resources/tutorials/add-a-block.mdx

@@ -20,15 +20,15 @@ Install reviews as a block and see it running everywhere it appears.
     Search the registry and inspect what the block ships before installing:
 
     ```bash
-    bunx @mercurjs/cli@rc search --query reviews
-    bunx @mercurjs/cli@rc view reviews
+    bunx @mercurjs/cli@latest search --query reviews
+    bunx @mercurjs/cli@latest view reviews
     ```
 
     `view` lists the block's files by target (API, admin, vendor) and its dependencies.
   </Step>
   <Step title="Install it">
     ```bash
-    bunx @mercurjs/cli@rc add reviews
+    bunx @mercurjs/cli@latest add reviews
     ```
 
     The CLI copies the source into the directories mapped by your `blocks.json` aliases and prints the block's post-install instructions — module registration, middlewares, migrations.
@@ -40,7 +40,7 @@ Install reviews as a block and see it running everywhere it appears.
     cd packages/api
     bunx medusa db:generate reviews
     bunx medusa db:migrate
-    bunx @mercurjs/cli@rc codegen
+    bunx @mercurjs/cli@latest codegen
     ```
   </Step>
   <Step title="See it live">
@@ -53,7 +53,7 @@ Install reviews as a block and see it running everywhere it appears.
 1. The block's files exist in your repo under the alias-mapped paths.
 2. Migrations ran cleanly and the API boots.
 3. The admin and vendor panels show their reviews pages; the store review endpoints respond.
-4. `bunx @mercurjs/cli@rc diff reviews` reports no drift from the registry.
+4. `bunx @mercurjs/cli@latest diff reviews` reports no drift from the registry.
 
 ## FAQ
 
@@ -62,7 +62,7 @@ Install reviews as a block and see it running everywhere it appears.
     The CLI asks before overwriting existing files (or force it with `--overwrite`). If you've customized a page the block also ships, merge by hand — you're merging source, not resolving package versions.
   </Accordion>
   <Accordion title="How do I update a block later?">
-    `bunx @mercurjs/cli@rc diff reviews` shows what changed in the registry since you installed. Take updates with `add reviews --overwrite`, re-applying any local edits afterwards.
+    `bunx @mercurjs/cli@latest diff reviews` shows what changed in the registry since you installed. Take updates with `add reviews --overwrite`, re-applying any local edits afterwards.
   </Accordion>
 </AccordionGroup>
 

package/content/resources/tutorials/build-a-block.mdx

@@ -58,7 +58,7 @@ Each file in a block carries a `type` that maps to an alias in the consumer's `b
           "description": "Marketplace announcements with a vendor portal feed.",
           "dependencies": [],
           "registryDependencies": [],
-          "docs": "## Setup\n\nRegister the module in `medusa-config.ts`, then run `bunx medusa db:generate announcements && bunx medusa db:migrate`, and finally `bunx @mercurjs/cli@rc codegen`.",
+          "docs": "## Setup\n\nRegister the module in `medusa-config.ts`, then run `bunx medusa db:generate announcements && bunx medusa db:migrate`, and finally `bunx @mercurjs/cli@latest codegen`.",
           "categories": ["module", "api", "vendor"],
           "files": [
             { "path": "announcements/modules/announcements/index.ts", "type": "registry:module" },
@@ -74,7 +74,7 @@ Each file in a block carries a `type` that maps to an alias in the consumer's `b
   </Step>
   <Step title="Build the registry">
     ```bash
-    bunx @mercurjs/cli@rc build
+    bunx @mercurjs/cli@latest build
     ```
 
     This reads `registry.json`, resolves each block's imports, embeds file contents, and writes one JSON per block into `r/` — `r/announcements.json`, plus an index `r/registry.json`.
@@ -94,7 +94,7 @@ Each file in a block carries a `type` that maps to an alias in the consumer's `b
     ```
 
     ```bash
-    bunx @mercurjs/cli@rc add @my-org/announcements
+    bunx @mercurjs/cli@latest add @my-org/announcements
     ```
 
     The CLI fetches the JSON, maps each file's `type` to the consumer's aliases, rewrites imports, and prints your `docs` instructions.
@@ -106,7 +106,7 @@ Each file in a block carries a `type` that maps to an alias in the consumer's `b
 1. `r/announcements.json` exists after the build and embeds every file's content.
 2. In the consumer project, the files landed under the alias-mapped paths and imports resolve.
 3. After following your own `docs` steps (module registration, migrations, codegen), `bun run build` passes and the vendor portal shows the Announcements page.
-4. `bunx @mercurjs/cli@rc diff @my-org/announcements` reports no changes — the installed copy matches the registry.
+4. `bunx @mercurjs/cli@latest diff @my-org/announcements` reports no changes — the installed copy matches the registry.
 
 ## FAQ
 

package/content/resources/tutorials/custom-api-route.mdx

@@ -43,7 +43,7 @@ A `GET /vendor/sales-summary` endpoint returning the seller's order count, calle
   </Step>
   <Step title="Regenerate the route map">
     ```bash
-    bunx @mercurjs/cli@rc codegen
+    bunx @mercurjs/cli@latest codegen
     ```
 
     Codegen scans your route files and rewrites the generated `Routes` type that your panel apps already import:
@@ -63,7 +63,7 @@ A `GET /vendor/sales-summary` endpoint returning the seller's order count, calle
     This file ships with the starter template — you don't need to touch it. After codegen, `client.vendor.salesSummary` simply exists, typed.
 
     <Tip>
-      Run `bunx @mercurjs/cli@rc codegen --watch` during development so the route map regenerates as you edit route files.
+      Run `bunx @mercurjs/cli@latest codegen --watch` during development so the route map regenerates as you edit route files.
     </Tip>
   </Step>
   <Step title="Call it from a panel page">

package/content/resources/tutorials/import-export-products.mdx

@@ -18,7 +18,7 @@ A vendor product list with **Import** and **Export** header buttons, a working C
 <Steps>
   <Step title="Install the block">
     ```bash
-    bunx @mercurjs/cli@rc add product-import-export
+    bunx @mercurjs/cli@latest add product-import-export
     ```
 
     The CLI copies the block's files into the directories mapped by your `blocks.json` aliases — workflows and routes into the API package, pages and hooks into the vendor app.
@@ -47,7 +47,7 @@ A vendor product list with **Import** and **Export** header buttons, a working C
     The block added `POST /vendor/products/import` and `GET /vendor/products/export`. Regenerate the route map so the vendor app's typed client knows about them:
 
     ```bash
-    bunx @mercurjs/cli@rc codegen
+    bunx @mercurjs/cli@latest codegen
     ```
 
     <Note>
@@ -68,7 +68,7 @@ A vendor product list with **Import** and **Export** header buttons, a working C
 1. The Products header shows Import and Export buttons; the rest of the page (search, filters, pagination) behaves exactly as before.
 2. The exported CSV contains the seller's products — and only theirs; the workflow scopes to the authenticated seller.
 3. After importing the edited CSV, the changed title appears in the product list.
-4. The block's source lives in your repo (e.g. `packages/api/src/workflows/import-seller-products.ts`, `apps/vendor/src/routes/products/page.tsx`) — run `bunx @mercurjs/cli@rc diff product-import-export` to compare against the registry later.
+4. The block's source lives in your repo (e.g. `packages/api/src/workflows/import-seller-products.ts`, `apps/vendor/src/routes/products/page.tsx`) — run `bunx @mercurjs/cli@latest diff product-import-export` to compare against the registry later.
 
 ## FAQ
 

package/content/tools/api-client.mdx

@@ -23,7 +23,7 @@ export const client = createClient<Routes>({
 ```
 
 <Info>
-  The `Routes` type is generated from your backend using `@mercurjs/cli@rc
+  The `Routes` type is generated from your backend using `@mercurjs/cli@latest
   codegen`. This gives the client full type safety with zero manual type
   definitions.
 </Info>
@@ -133,7 +133,7 @@ try {
 
 <AccordionGroup>
   <Accordion title="Why is a route missing from the client after I added it?">
-    The client's types come from the generated route map — run `bunx @mercurjs/cli@rc codegen` after adding or changing route files. During development, `codegen --watch` keeps the map current automatically.
+    The client's types come from the generated route map — run `bunx @mercurjs/cli@latest codegen` after adding or changing route files. During development, `codegen --watch` keeps the map current automatically.
   </Accordion>
   <Accordion title="How are URLs derived from property access?">
     Each property becomes a kebab-cased path segment (`client.vendor.salesSummary` → `/vendor/sales-summary`), `$`-prefixed keys fill path parameters, and the terminal method picks the HTTP verb: `query` → GET, `mutate` → POST, `delete` → DELETE.

package/content/tools/cli.mdx

@@ -3,12 +3,12 @@ title: "CLI"
 description: "Install blocks, scaffold projects, and generate types from the command line."
 ---
 
-The Mercur CLI (`@mercurjs/cli@rc`) manages your marketplace project — installing blocks, generating types, and checking for updates. To create a new project, use [`create-mercur-app`](https://www.npmjs.com/package/create-mercur-app).
+The Mercur CLI (`@mercurjs/cli@latest`) manages your marketplace project — installing blocks, generating types, and checking for updates. To create a new project, use [`create-mercur-app`](https://www.npmjs.com/package/create-mercur-app).
 
 ## Installation
 
 ```bash
-bun add -g @mercurjs/cli@rc
+bun add -g @mercurjs/cli@latest
 ```
 
 ## Commands
@@ -18,9 +18,9 @@ bun add -g @mercurjs/cli@rc
 Scaffolding new projects lives in the standalone [`create-mercur-app`](https://www.npmjs.com/package/create-mercur-app) package, so it downloads fast and works with every package manager's `create` command.
 
 ```bash
-bun create mercur-app@rc my-marketplace
+bun create mercur-app@latest my-marketplace
 # or
-npm create mercur-app@rc my-marketplace
+npm create mercur-app@latest my-marketplace
 ```
 
 It will prompt you for database credentials and install dependencies automatically.
@@ -37,7 +37,7 @@ It will prompt you for database credentials and install dependencies automatical
 Initialize an existing project by creating a `blocks.json` configuration file.
 
 ```bash
-bunx @mercurjs/cli@rc init
+bunx @mercurjs/cli@latest init
 ```
 
 This sets up path aliases so the CLI knows where to place blocks in your project:
@@ -62,8 +62,8 @@ This sets up path aliases so the CLI knows where to place blocks in your project
 Install blocks from the registry into your project.
 
 ```bash
-bunx @mercurjs/cli@rc add wishlist
-bunx @mercurjs/cli@rc add product-review order-tracking
+bunx @mercurjs/cli@latest add wishlist
+bunx @mercurjs/cli@latest add product-review order-tracking
 ```
 
 Blocks are copied directly into your project as source code. The CLI resolves dependencies, transforms imports to match your path aliases, and installs required packages.
@@ -79,7 +79,7 @@ Blocks are copied directly into your project as source code. The CLI resolves de
 Find available blocks in the registry.
 
 ```bash
-bunx @mercurjs/cli@rc search --query wishlist
+bunx @mercurjs/cli@latest search --query wishlist
 ```
 
 | Option | Description |
@@ -92,7 +92,7 @@ bunx @mercurjs/cli@rc search --query wishlist
 Display detailed information about a block.
 
 ```bash
-bunx @mercurjs/cli@rc view wishlist
+bunx @mercurjs/cli@latest view wishlist
 ```
 
 ### diff
@@ -100,13 +100,13 @@ bunx @mercurjs/cli@rc view wishlist
 Compare local blocks against registry versions to check for updates.
 
 ```bash
-bunx @mercurjs/cli@rc diff wishlist
+bunx @mercurjs/cli@latest diff wishlist
 ```
 
 If there are changes you want, update with:
 
 ```bash
-bunx @mercurjs/cli@rc add wishlist --overwrite
+bunx @mercurjs/cli@latest add wishlist --overwrite
 ```
 
 ### codegen
@@ -114,7 +114,7 @@ bunx @mercurjs/cli@rc add wishlist --overwrite
 Generate TypeScript types from your API routes. Used by the [API Client](/rc/tools/api-client) for type-safe requests.
 
 ```bash
-bunx @mercurjs/cli@rc codegen
+bunx @mercurjs/cli@latest codegen
 ```
 
 | Option | Description |
@@ -126,7 +126,7 @@ bunx @mercurjs/cli@rc codegen
 Build a custom registry from a `registry.json` file.
 
 ```bash
-bunx @mercurjs/cli@rc build
+bunx @mercurjs/cli@latest build
 ```
 
 | Option | Description |
@@ -139,7 +139,7 @@ bunx @mercurjs/cli@rc build
 Display project configuration and diagnostics.
 
 ```bash
-bunx @mercurjs/cli@rc info
+bunx @mercurjs/cli@latest info
 ```
 
 ### telemetry
@@ -147,8 +147,8 @@ bunx @mercurjs/cli@rc info
 Control anonymous usage data collection.
 
 ```bash
-bunx @mercurjs/cli@rc telemetry --disable
-bunx @mercurjs/cli@rc telemetry --enable
+bunx @mercurjs/cli@latest telemetry --disable
+bunx @mercurjs/cli@latest telemetry --enable
 ```
 
 ## Custom registries
@@ -167,7 +167,7 @@ Add custom block registries to your `blocks.json`:
 Use `{name}` as a placeholder for block names. Reference custom registries with the `-r` flag:
 
 ```bash
-bunx @mercurjs/cli@rc search --query review --registry @my-registry
+bunx @mercurjs/cli@latest search --query review --registry @my-registry
 ```
 
 ## FAQ

package/llms.txt

@@ -14,6 +14,7 @@ package (`node_modules/@mercurjs/docs/`).
 - [Concepts](content/learn/concepts.mdx) — Core concepts behind Mercur — from the Medusa foundation to blocks, panels, and the registry.
 - [Installation](content/learn/installation.mdx) — Install Mercur and set up your marketplace project.
 - [Introduction](content/learn/introduction.mdx) — Mercur is an open-source marketplace platform built on MedusaJS with a block-based architecture.
+- [Mercur - an open-source Mirakl alternative](content/learn/mirakl-alternative.mdx) — How Mercur compares to Mirakl and other marketplace platforms: open-source, self-hosted, no GMV fees, full code ownership.
 - [Offers](content/learn/offers.mdx) — An offer is a seller's sellable listing against a master product — their own SKU, price, inventory, and shipping.
 - [Order Groups](content/learn/order-groups.mdx) — How multi-seller checkout creates order groups — the container that ties a single cart to multiple seller orders.
 - [Payout](content/learn/payouts.mdx) — How seller payouts work in Mercur — accounts, onboarding, payment capture, and the transfer pipeline.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mercurjs/docs",
-  "version": "2.2.0",
+  "version": "2.2.1-canary.1",
   "repository": {
     "type": "git",
     "url": "https://github.com/mercurjs/mercur",