Commit activity
Last 12 weeks · 1 commit
Community health
2 of 6 standards met
Recent PRs & issues
Add a Kane CLI natural-language end-to-end test This adds one plain-markdown, natural-language end-to-end test covering opening the Commerce demo storefront, opening a product, adding it to the cart, and verifying the cart updates. Why it might help Readable by anyone: no selectors, no scripting. It lives in the repo as a and re-runs on every deploy. Kane CLI drives a real browser, verifies each step with a visual/network check, and produces a sharable evidence report (video, steps, network). It also automates mobile apps on the iOS Simulator and Android Emulator. Evidence from a live run (passed): https://test-manager.lambdatest.com/projects/01KJSH1ECPR455A3XRGBKR3NV3/test-cases/01M255AGZ4D8H2N8C40PQMZGTY/dashboard/share/US_4OKRGB03HDJFCTVKGC8JL2RKO91XKDBLMWQNIF1U7R77S5SGXZ6C9ZPUMGQOLHGO?type=summary&agentView=true&fqdn=summary-page How to run** Opening this for your consideration; approval is entirely yours. Happy to adjust the flow, the file location, or the format.
Fixes #1503 Wrapped the call inside in try/catch. On any failure it now logs (, matching the existing "Skipping ... - Shopify not configured" logging style already in this file) and returns , same as the site's already-established behavior for an unconfigured store. Navbar/Footer already render fine with an empty menu array (), so this degrades to "no nav/footer links" instead of "site doesn't build." Scope: only . I deliberately did not add the same try/catch to ///etc. — those are only used on their own specific routes, so a failure there fails just that one page (arguably correct — you want a real error/404 for a missing product), not every route via the shared layout. Widening this pattern further would be a product decision I'm not making here. Verification
Recent fixes
We're making some updates to Next.js Commerce. Everything prior to this PR marks what we're calling as a point in time to be able to reference and still use going into the future. The current architecture of Commerce is a multi-vendor, interoperable solution, including: Shopify Swell BigCommerce Vendure Saleor Ordercloud Spree Kibo Commerce Commerce.js SalesForce Cloud Commerce All features can be toggled on or off, and it's easy to change between commerce providers. To support this, we needed to create a "commerce metaframework" where providers could confirm to an API spec to add support for Next.js Commerce. While this worked and was successful for , we have different design goals and ambitions for . What You Need To Know** will not be updated moving forward. If you need to reference , you will still be able to clone and deploy the version tagged at this release. will be shifting to be a single provider vs. provider agnostic. Other providers are welcome to fork this repository and swap out the underlying implementation that connects to the selected commerce provider (Shopify). This architecture was chosen to reduce the surface area of the codebase, remove the intermediate metaframework layer for provider-interoperability, and enable usage with the latest Next.js and React features. We will be sharing more about in the future as we continue to iterate before the marked release. Thank you so much! 🎉
Track the products a shopper opens in localStorage and show them in a "Recently Viewed" strip under Related Products. Reads go through useSyncExternalStore so the list stays in sync across tabs without setState-in-effect, and stored entries are validated before rendering. Also escape "" cannot break out of the script tag.
Repository: vercel/commerce. Description: Next.js Commerce Stars: 14314, Forks: 5475. Primary language: TypeScript. Languages: TypeScript (99.2%), CSS (0.7%), JavaScript (0.1%). License: MIT. Topics: ecommerce, nextjs, react, shopify. Latest release: v1 (3y ago). Open PRs: 25, open issues: 55. Last activity: 1d ago. Community health: 62%. Top contributors: okbel, lfades, cond0r, manovotny, Francam94, julianbenegas, leerob, pacocoursey, goncy, martinbavio and others.