Website ·
Running in production ·
Backends ·
Themes ·
Docs
Svelte Commerce is a production-ready open-source headless ecommerce storefront built with SvelteKit and TypeScript. It connects to commerce backends through APIs, so you can build fast, SEO-friendly storefronts independently of your ecommerce backend — Shopify, WooCommerce, Vendure, Saleor, Medusa and 21 more.
Backend support
Svelte Commerce talks to any backend through a connector package. No file in this repo names a
connector. Every service resolves through $lib/core/services, and which connector answers is
decided by what package.json installs. Switching backends is two steps:
1. Install the connector in place of the stock one, so npm i — and any Docker build, which
installs from package.json alone — resolves it:
npm uninstall @misiki/litekart-connector
npm i @misiki/shopify-connector # or vendure, medusa, saleor, ...
2. Set that backend's env in .env — PUBLIC_SHOPIFY_API_URL, PUBLIC_MEDUSA_API_URL, the
PUBLIC_LITEKART_* trio, and so on. The convention is PUBLIC_<BACKEND>_API_URL, with any extra
credentials read from the same prefix, so a connector this repo has never heard of configures
itself the same way. Per-backend guides are in docs/.
There is no third step, and nothing to uncomment. vite.config.ts resolves whichever
@misiki/*-connector is installed and exposes it as $connector;
src/lib/core/connectors/active.ts is the one module that wraps it, for every backend. Set
PUBLIC_CONNECTOR to override that — to attach a connector this repo has never heard of
(PUBLIC_CONNECTOR='@my-co/custom-connector'), or to choose when several are installed.
@misiki/kitcommerce-core imports @misiki/litekart-connector by name — its peerDependency — so
a shim in vite.config.ts redirects that specifier onto the connector you installed. It does
nothing while Litekart is installed.
All 26 connectors — and a request to the people who build these platforms
Each connector maps one platform's API onto a shared 43-service surface (product, cart,
checkout, order, auth, address, …). Coverage below is measured, not asserted: a script
traces which services actually reach the HTTP layer, following each connector's own request helpers.
Every endpoint was written by reading the platform's authoritative source — the OpenAPI spec,
the RAML, the router registration, or the controller code itself. We did not guess routes, and
where a route could not be verified we left an explicit placeholder rather than ship a
plausible-looking path that 404s in a merchant's store.
But none of these have been run against a live production instance. That is the single biggest
gap, and the one thing platform maintainers can fix that we cannot.
This is the beginning of the README. Read the rest at the original. Read the full README ↗
