svelte-commerce

Svelte Commerce

The production-ready open-source headless commerce storefront

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.

✅ wired · ⛔ throws NotSupportedError — the platform has no real endpoint, and a stub that mints a session for any password is an auth bypass, not a placeholder · — not yet wired

A low number is often the correct answer, not a to-do. OpenCart core ships exactly ten API controllers — cart, coupon, currency, customer, login, order, payment, reward, shipping, voucher — and no product, category or search controller at all. Its 9/43 is the honest ceiling for that API. Services excluded from “help wanted” are Litekart-native concepts (reels, deals, chat, gallery, popularity, banner, …) that have no equivalent on any third-party platform.

📣 How you can help

If you build or maintain one of these platforms, in priority order:

1. A sandbox or demo instance we can point a storefront at. Even short-lived. Worth more than any code review — it turns “verified against the spec” into “verified against reality”.
2. Ten minutes telling us our idioms are wrong. We picked one way to do pagination, filtering, sorting and session handling per platform. If it is not how you would do it, saying so saves us a wrong assumption baked into every service.
3. Answers on the gaps above. Most are “does this platform have X at all?” — instant for you, guesswork for us.
4. A pointer to the right docs. Three URLs we were given were dead (spree.readthedocs.io, api.sylius.com, django-oscar-api’s route page) and we fell back to reading source.

Per-platform open questions are in CONNECTORS.md — e.g. does Shopware’s Store API have standalone voucher lookup? Is REST planned for Magento_Review/Magento_Wishlist, which ship no webapi.xml? Is listing → Product the mapping Sharetribe would recommend?

Open an issue or PR on the connector repo under github.com/misiki-in, or start a discussion. We will credit you in the connector README.

Storefront capability matrix

✅ supported · ❌ not implemented yet · ❓ untested

Litekart is the reference implementation and is the most complete. The Medusa, Vendure and Saleor connectors cover the core commerce path — browse, product, cart, checkout, order — and are actively being extended. PRs welcome.

Maintainers of these platforms: we would rather ask than guess. The fastest way to help is a sandbox instance we can point a storefront at, or ten minutes telling us our endpoint idioms are wrong. Specific open questions per platform are in CONNECTORS.md.

Required backend settings

Each backend needs a few settings changed before the storefront will work end to end.

Vendure

• authOptions.requireVerification → false

See VENDURE.md for the full Vendure setup guide (env, store identity, architecture, limitations, troubleshooting).

Saleor

• Require email confirmation for user registration → false
• isPhoneMandatory → false
• Allow unpaid orders in order settings → enabled
• Allow unpaid orders in channel settings → enabled

See SALEOR.md for the full Saleor setup guide.

Medusa

• Set a publishable API key and add your storefront origin to the Store CORS config.

See MEDUSA.md for the full Medusa setup guide.

Demos