Next.js Commerce adapter
Already know Vercel’s Next.js Commerce?
You can back it with Flightdeck instead of Shopify by dropping in our
lib/flightdeck provider.
Next.js Commerce is Shopify-focused but designed for exactly this: its docs say
alternative providers should “fork this repository and swap out the lib/shopify
file with their own implementation while leaving the rest of the template mostly
unchanged.” lib/flightdeck is that implementation, backed by
@dscodotco/sdk.
The adapter lives at examples/nextjs-commerce-adapter/ in the platform repo —
its README.md has the complete mapping table and the sample checkout route.
Swap it in
- Fork
vercel/commerce. - Delete
lib/shopify/. - Copy
lib/flightdeck/(from the example) into your fork. - Update imports from
lib/shopify->lib/flightdeck. - Set env:
FLIGHTDECK_API_URL,FLIGHTDECK_TENANT,FLIGHTDECK_STOREFRONT_TOKEN. - Copy the sample
app/api/checkout/route.ts— it’s the target of the cart’scheckoutUrl.
The adapter exports the same function names and signatures as lib/shopify
and returns byte-compatible normalized types, so the rest of the template
compiles unchanged.
What maps cleanly
Catalog is a clean map — getProducts, getProduct, getCollection,
getCollections, getCollectionProducts all resolve through the SDK, with
prices converted from integer cents to Next.js Commerce’s Money shape, and
honest absence preserved (unknown -> undefined/[], real errors throw).
The one real difference — the cart
Next.js Commerce expects a server-side cart with a checkoutUrl (Shopify’s
model). Flightdeck has no server cart and no hosted checkout — checkout is
one-shot. So the adapter implements a cookie-backed cart: the fd_cart
cookie holds only { variantId, handle, quantity } (no prices), and every
getCart() re-prices from the live catalog (tamper-proof; discontinued lines
pruned only on a real 404). The cart’s checkoutUrl points at a first-party
/api/checkout route that calls store.checkout.submit. Your fork owns the
payment-form UI, because Flightdeck takes the card directly.
Honest gaps (documented, not faked)
Some Next.js Commerce functions have no Flightdeck equivalent yet. The adapter does not fabricate data for them:
| Function | Behavior | Why |
|---|---|---|
getPage / getPages | undefined / [] | No CMS pages surface yet. |
getMenu | derived from collections | No dedicated menu concept. |
getProductRecommendations | naive “other products” | No recommender yet. |
revalidate | no-op | No catalog webhook yet. |
Field-level: updatedAt is empty (no catalog timestamps), image dimensions are
0 (opaque asset refs), descriptionHtml is the plain description, tax/shipping
are unknown until checkout. These are called out in the adapter README so you
know exactly what’s real.
When to use the adapter vs the starter
- Adapter — you already have a Next.js Commerce build or want its exact UX/component library, and you’re comfortable owning a fork.
- Starter — you want the fastest path and a store tailored to Flightdeck (age gates, RUO disclaimers, the compliance surfaces) without a fork. See Getting started.