swirepay-sdk

A framework-agnostic set of web components (Svelte 5 under the hood), distributed as a standalone bundle — embed them the same way you'd drop in a Stripe Elements <script> tag, no build step or framework required on the consuming page.

Developing

npm install
npm run dev

This serves index.html at the project root, which loads the element straight from source for local preview: <swirepay-contact-onboarding></swirepay-contact-onboarding>.

Project structure

src/lib/
  elements/    the custom element(s) registered via <svelte:options customElement="...">
  components/  internal Svelte components composed inside an element's shadow root
  store/       per-instance state (Svelte 5 runes classes), shared via context
  styles/      shared design tokens (CSS custom properties), inlined into each
               element's shadow root — see styles/tokens.css
  index.ts     public entry point; importing it registers the custom element(s)

Because each root element renders inside its own shadow DOM, --swp-* tokens declared once in styles/tokens.css are inherited by every nested component automatically — no per-component imports needed.

Building

npm run build:dev   # dist/dev  — unminified, sourcemapped, debug logging on
npm run build:prod  # dist/prod — minified, no sourcemaps, debug logging off
npm run build       # alias for build:prod; this is what gets published

Each produces two self-contained bundles (Svelte's runtime is inlined, so nothing else needs to be loaded) plus a .d.ts:

• swirepay-sdk.js — ES module, for consumers using a bundler or <script type="module">
• swirepay-sdk.iife.js — classic script, for a plain <script src="..."> tag
• swirepay-sdk.d.ts — type declarations for the custom elements

dist/dev and dist/prod can coexist, e.g. to deploy the dev build to a staging CDN path alongside the prod build on the production path. Only dist/prod is included when the package is published (see files in package.json).

Publishing

Set the package name/version in package.json, then:

npm publish