Skip to content

harder-labs/vendure-plugins

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

harder-labs/vendure-plugins

Vendure 3.6+ plugins maintained by Harder Labs. Modeled on Pinelab's vendure-plugins monorepo: yarn workspaces + Lerna independent versioning, per-package CI, a _template/ package for new plugins.

Packages

Package Description
@harder-labs/vendure-plugin-printful Idempotent fulfillment submission + raw-body HMAC webhook dedupe for Printful POD.
@harder-labs/vendure-plugin-magic-link Passwordless auth — peppered SHA-256 tokens, per-IP + per-email Redis rate limiting, anti-probe responses.

Each package publishes independently. See its own README for env contract and usage; see its CHANGELOG.md for the version history.

Why a separate repo

These plugins started in-tree in harder-labs/vendure-platform during Phase 0 of the HCG build. Once the contracts stabilized and gpt-5.4 had reviewed them (vendure-platform task #14), extraction unblocks:

  • npm publishing under @harder-labs/*
  • reuse across Harder Labs commerce projects (HCG, Stellar Arcade, future) without copy-paste
  • contributor PRs that don't need access to the platform repo

The platform repo consumes these via file: deps locally and via published versions in CI/prod. The mailerlite-bridge plugin stays in-tree in the platform repo because it's HCG-specific glue (channel-scoped MailerLite API keys, HCG list IDs).

Dev workflow

nvm use            # 22.22.1
yarn install       # bootstraps all workspaces
yarn build         # build every package (lerna run build)
yarn test          # vitest in every package

cd packages/vendure-plugin-printful
yarn build         # iterate one package
yarn test          # iterate one package's tests

After editing a package, rebuild it (yarn build in the package dir) so the local file: consumer in ~/code/vendure-platform picks up the change on next npm install. A --watch mode is on the roadmap once we have more than two packages making this painful.

Adding a new plugin

cp -R packages/_template packages/vendure-plugin-<name>
# edit package.json: name + description + keywords
# edit src/index.ts to export the plugin

The _template/ package has the canonical wiring — tsconfig, vitest config, package.json scripts, CHANGELOG seed.

CI

  • Pull requests: .github/workflows/test.yaml builds + tests every package whose packages/<name>/ tree changed, or every package when the root workspace or packages/test/ / packages/util/ change.
  • Push to main: .github/workflows/publish.yaml (gated, planned — currently scaffolded but the NPM_PUBLISH_TOKEN secret is unset). When enabled, it publishes any package whose local version differs from the npm registry version.

Versioning model

Independent — each package versions on its own using lerna version --no-git-tag-version, following SemVer. chore(release): publish <pkg>@<version> commits are made by the release flow once it's wired up; for now, edit package.json directly and let CI handle the npm publish on merge.

License

MIT

About

Vendure 3.6+ plugins maintained by Harder Labs (extracted from vendure-platform)

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors