Svelte Commerce

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.

Platform	npm package	Coverage	Cart	Checkout	Order	Auth	Help wanted with
Litekart	@misiki/litekart-connector	39/43	✅	✅	✅	✅	—
Vendure	@misiki/vendure-connector	39/43	✅	✅	✅	✅	—
Medusa	@misiki/medusa-connector	31/43	—	✅	✅	⛔	address, auth, cart, category, payment-method, product, search, user
Broadleaf Commerce	@misiki/broadleaf-connector	28/43	✅	✅	✅	✅	—
Saleor	@misiki/saleor-connector	28/43	—	—	—	⛔

✅ 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

Capability	Litekart	Shopify	Medusa	Vendure	Saleor	WooCommerce
Product listing / search	✅	✅	✅	✅	✅	✅
Product detail page	✅	✅	✅	✅	✅	✅
Categories / collections	✅	✅	✅	✅	❓	✅
Cart	✅	✅	✅	✅	✅	✅
Checkout	✅	✅	✅	✅	✅	✅
Payment methods	✅	✅	✅	✅	✅	✅
Order placement	✅	✅	✅	✅	✅	✅
Order history / detail	✅	✅	✅	✅	✅	✅
Auth / registration	✅	✅	✅	✅	✅	✅
Addresses	✅	✅	✅

✅ 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

Backend	Demo
Litekart	https://arialshop.com/
Medusa	add URL
Vendure	add URL
Saleor	add URL

What is it?

• Svelte Commerce is a PWA storefront for your existing eCommerce based on SvelteKit.
• It is possible to connect with any eCommerce backend that provides an API.
• We are working on adapters for Medusa, Shopify, and WooCommerce.

Get Started

git clone https://github.com/itswadesh/svelte-commerce.git
cd svelte-commerce
cp .env.example .env
npm install
npm run dev

.env.example points at the public Litekart demo API, so the storefront works straight away. Edit .env to point at your own backend, and see Backend support to switch connectors.

Open http://localhost:5173 — your storefront should be up and running.

Other useful scripts:

npm run build     # production build
npm run preview   # preview the production build locally
npm start         # run the built app with the Node adapter
npm run check     # sync connector types + svelte-check

Configuration

Two files: kitcommerce.config.ts and .env.

1. Backend and connector package — the three steps in Backend support above.
2. Store identity — kitcommerce.config.ts's default export holds overrides (name, logo, favicon, currency, menus, plugins, cssVariables), merged over src/lib/core/connectors/default-store.json. Leave it {} on Litekart: the API serves all of it.
3. Env — copy .env.example to .env. Each backend's variables are listed in its platform guide.

Documentation

Full docs live in docs/, including a setup guide for every one of the 26 supported backends:

• docs/README.md — index of all 26 platform guides, with coverage and wiring status
• CONNECTORS.md — the capability matrix and open questions for platform maintainers
• Most complete: LITEKART.md · VENDURE.md · MEDUSA.md · SALEOR.md
• Also supported: SHOPIFY.md · WOOCOMMERCE.md · MAGENTO.md · SHOPWARE.md · COMMERCETOOLS.md · and 17 more
• CHANGELOG.md — release history

Deployment

Click on the button to directly deploy to Netlify, Vercel or ZopDay. Zero configuration required.

Docker

We also support docker images, use the following command to pull the latest docker image and deploy it:

docker run -d -p 3000:3000 ghcr.io/itswadesh/svelte-commerce:latest