Svelte Commerce × Litekart
Svelte Commerce on Litekart
Litekart is the backend Svelte Commerce ships with, and the reference implementation every other connector is written against. A fresh clone already runs on it: the example environment points at Litekart’s public demo API.
- 39/43 services wired
- @misiki/litekart-connector 2.0.30
- Cart wired
- Checkout wired
- Sign-in (auth) wired
What works on Litekart today
The most complete connector, and the default: 39 of 43 services, with cart, checkout and sign-in wired. It is the only backend whose API serves the whole storefront — CMS pages, blog, menus, search autocomplete, wishlist, coupons and the shopping assistant.
Cart
Wired: issues a real request to Litekart.
Checkout
Wired: issues a real request to Litekart.
Sign-in (auth)
Wired: issues a real request to Litekart.
Known gaps: none — Litekart is the reference implementation every other connector is written against.
39 of 43 services wired, read from CONNECTORS.md on , where the package version is recorded too; npm may carry a newer patch. Coverage is traced by a script in the Svelte Commerce repository: a service counts as wired only if it transitively issues an HTTP request, or delegates to one that does. It is not hand-asserted.
Quick start
From nothing to a Svelte Commerce storefront reading Litekart. You need Node.js and a Litekart to point it at; the storefront holds no data of its own.
Clone it, choose the connector, point it at Litekart
# 1 — get the storefront
git clone https://github.com/itswadesh/svelte-commerce
cd svelte-commerce
# 2 — install: the Litekart connector is already in package.json
npm install
# 3 — use the example env, which points at the public demo API
cp .env.example .env
# 4 — run it
npm run devNothing to swap. A fresh clone lists both @misiki/litekart-connector and @misiki/vendure-connector; with Litekart’s installed, the build prefers it.
Environment variables
| Variable | Required | What it does |
|---|---|---|
PUBLIC_LITEKART_API_URL | Yes | Base URL of the Litekart API, such as https://api.litekart.in. In dev, Vite also proxies /api here, falling back to localhost:7000. |
PUBLIC_LITEKART_DOMAIN | Yes | The store’s domain, such as arialshop.com. Used to look up the store when no litekart_store_id cookie is present. |
PUBLIC_LITEKART_STORE_ID | Yes | Needed in production. Serves this store directly, skipping the domain lookup; src/hooks.server.ts writes it to the litekart_store_id cookie. |
/health returns 503 and names whatever is missing; on Litekart it requires all three. Litekart’s connector reads and checks this trio itself — it is the one backend init.ts leaves alone.
Every variable here begins PUBLIC_, and SvelteKit sends PUBLIC_ variables to the browser: treat each value you set as published.
What to set up on Litekart
- Nothing to switch in the storefront:
package.jsonships@misiki/litekart-connector, andkitcommerce.config.tsnames no backend. - Store details — name, logo, currency, menus, plugin toggles and theme CSS variables — come live from the Litekart API (
/api/stores/public-details), so the default export ofkitcommerce.config.tsis normally left empty. - Choose the theme in the Litekart admin. The API serves that theme’s content, layout and CSS, and
store.themewins overPUBLIC_STOREFRONT_THEME;src/lib/theme/index.tshas the full order of precedence.
How the integration works
Litekart is the REST API the other 25 connectors inherit their paths from. kitcommerce.config.ts exports its services from src/lib/core/connectors/active, which on Litekart is a plain re-export of @misiki/litekart-connector — the one backend that needs no service overrides.
The active backend is named by a connectorName marker — litekart here — and that is what /health, init and the shopping assistant read to know which backend is running.
Because the API is authoritative for the store record, the static src/lib/core/connectors/default-store.json that other backends fall back on is never read in Litekart mode.
Limitations
- CONNECTORS.md records no known gaps — it lists Litekart as the reference implementation — but the coverage script counts 39 of the 43 services as wired, not all 43.
- The features only Litekart serves — CMS pages, blog, menus, Meilisearch autocomplete, wishlist, coupons and the Conversational Shopping assistant — fall back to static theme content, or disappear, if you later move to another backend.
- A production Node build and Docker read
PUBLIC_*from the process environment, not from.env: all three variables have to be set on the deploy platform.
Troubleshooting
| When you see | What to do |
|---|---|
| “Unable to retrieve hostname from URL” | Neither PUBLIC_LITEKART_DOMAIN nor a resolvable request hostname was available. Set the domain explicitly. |
/health returns 503 | The response names the missing variables. In production all three Litekart variables are required. |
| The wrong store is served | A stale litekart_store_id cookie. Setting PUBLIC_LITEKART_STORE_ID overwrites it on the next request. |
| Docker or production shows API errors that dev did not | The Node server reads PUBLIC_* from the process environment, not from .env. Set them on your deploy platform; docker-compose.yml shows where. |
Before you rely on it
The one caveat that matters
Read this before choosing
Every connector was written by reading its platform’s authoritative source — an OpenAPI spec, a RAML file, a router registration or the controller source — rather than by running against a store. No connector has been exercised against a live production instance of its platform.
Litekart is the one backend with public evidence beside it: the stores on the live projects page run Svelte Commerce against the Litekart API. This site has not checked which version of the connector each of them uses.
Offer a sandbox or a correctionFAQ
Questions about Svelte Commerce on Litekart
Do I need to install anything to run Svelte Commerce on Litekart?
No. Litekart is the stock backend: package.json already lists @misiki/litekart-connector, and the example environment points at Litekart’s public demo API, so copying .env.example to .env and starting the dev server gives you a working store.
Why is Litekart the most complete backend?
It is the reference implementation. Every other connector copies its method names and shapes, and Litekart’s API is the only one that serves the whole storefront — CMS pages, blog, menus, search autocomplete, wishlist, coupons and the shopping assistant included.
Do real stores run Svelte Commerce on Litekart?
Yes. The stores on this site’s live projects page run Svelte Commerce as their storefront, most of them backed by the Litekart API. None of them runs GoCommerce.
What does Svelte Commerce need from Litekart in production?
Three variables — PUBLIC_LITEKART_API_URL, PUBLIC_LITEKART_DOMAIN and PUBLIC_LITEKART_STORE_ID — set in the server’s process environment rather than .env. /health returns 503 and names any that are missing.
Sources
This page summarises LITEKART.md in the Svelte Commerce repository and the Litekart connector’s source, read on , and the coverage in CONNECTORS.md, read on . Where they disagree with this page, they are right and this page is out of date. Litekart is a trademark of its owner, named here only to describe compatibility; no endorsement or affiliation is implied — see trademarks.
Read the whole guide
The storefront is the same on every backend; the connector is what changes. LITEKART.md has the Litekart setup in full, beside the connector’s source.