Adocommerce Kit’s source tree is aligned to the lockstep 1.2.0 Indonesia release candidate. Registry publication remains blocked until the sanitized ID-30 checklist and three-merchant ID-31 pilot evidence pass pnpm s4:release. Every package remains beta or experimental after publication; the numeric version does not imply stable support.
Pin exact versions in controlled deployments:
{
"dependencies": {
"@adocommercekit/core": "1.2.0",
"@adocommercekit/storefront-api": "1.2.0",
"@adocommercekit/midtrans": "1.2.0",
"@adocommercekit/id": "1.2.0",
"@adocommercekit/biteship": "1.2.0"
}
}Use exact lockstep versions in production pilots; upgrade every installed official package together.
Current tiers
| Surface | Tier | Compatibility expectation |
|---|---|---|
@adocommercekit/core |
Beta | Generic deferred/COD payment, dynamic quote, fulfillment, return, metadata, instruction, and PDP-supporting contracts are additive but not yet stable. |
@adocommercekit/storefront-api |
Beta | The 14-endpoint baseline is host-owned; upgrade conflicts are review-only and are never overwritten. |
@adocommercekit/admin-api |
Beta | The 38-endpoint management baseline is host-owned; ability names are frozen, so additions are minor and renames are breaking. |
@adocommercekit/stripe |
Beta | Existing PaymentIntent behavior remains the default-inert baseline; hosts still own a complete SCA user experience. |
@adocommercekit/midtrans |
Beta | Core API v2 channels, signed notifications, expiry, and refund guidance require pinned credentials and current provider checks. |
@adocommercekit/xendit |
Beta | Payment Requests 2024-11-11 is pinned and must be revalidated before each release. |
@adocommercekit/id |
Beta | Region delivery is importer-only; tax and PDP mechanisms do not replace merchant counsel or controller duties. |
@adocommercekit/biteship |
Beta | API v1 rates and fulfillment require sandbox/production conformance for each enabled courier service. |
@adocommercekit/rajaongkir |
Experimental | Komerce API v1 rates/tracking are supported; waybill, fulfillment, COD, and insurance remain explicitly unsupported. |
@adocommercekit/whatsapp |
Experimental | Sends require approved templates, current purpose consent, a durable queue, and a host-configured fallback. |
| Queue adapter | Experimental | May change while @adonisjs/queue remains pre-1.0. |
@adocommercekit/admin |
Experimental | The Inertia + React panel publishes host-owned pages plus a vendored coss/Bklit UI tree; the page, primitive, and chart sets are closed lists, and the vendored registry revisions are pinned and hash-recorded per release. |
What beta means
Releases document every contract change and preserve host data, but the project has not yet claimed the adoption evidence required by its stable-release gate:
- migration and publication changes require host review;
- generated files can conflict with local edits and require a manual three-way merge;
- exact behavior should be covered by the host application’s checkout and provider tests;
- security fixes may require prompt upgrades.
Release channels
latest: reviewed tagged release only;1.2.0must not receive this tag until the S4 gate passes.beta: prerelease for the next reviewed version.canary: commit-level integration packages; never use an unconstrained canary range in a deployment.
All official packages must stay on one version. Release notes should identify schema stubs, publication changes, state additions, driver contract changes, and required host actions.
Upgrade policy
Whenever package versions change:
node ace commerce:upgrade
node ace commerce:doctorReview generated files and migrations, resolve conflicts, and run the host’s complete checkout and payment smoke before deployment. Follow the upgrade procedure.
Compatibility floor
Official packages are ESM-only and require:
- Node.js 24 or newer;
- AdonisJS 7;
- Lucid 22 for database-backed packages;
- a peer dependency version allowed by each package manifest.
PostgreSQL, MySQL, and SQLite are covered by the published schema branches. The host application owns framework upgrades, database compatibility, and generated schema history.
Path to stable
A stable support-tier claim requires more than local completion or the ID-31 pilot. It requires subsequent external use by at least two independent teams and separately documented adoption evidence. Until that later evidence exists, describe packages as beta or experimental even when one integration is production-quality for a specific host.