Skip to content

v0.1.4 — validation normalization, allowance amount guard, crypto guards

Choose a tag to compare

View all tags
@linyiru linyiru released this 18 Jun 20:19
· 16 commits to main since this release
v0.1.4
f633e39

Patch release across all packages — correctness and error-model improvements (no breaking changes).

Highlights

  • Allowance amount validation (fix). amountSummarySchema now enforces salesAmount + taxAmount === totalAmount on allowances, not just invoices — allowance() rejects an inconsistent amount locally instead of sending it to the provider.
  • Normalized validation errors. Adapter input validation now rejects with an InvoiceError (code VALIDATION, with the provider name and offending field) instead of leaking a raw ZodError, so every operation honors the SDK contract. (amego / ECPay / ezPay)
  • Clear crypto key/IV errors. A wrong-length HashKey / HashIV now throws a message naming the field and actual byte count, instead of an opaque Node createCipheriv error (ECPay 16/16, ezPay 32/16).
  • InvoiceError.toJSON(). Structured logging keeps the normalized fields (code / rawCode / rawMessage) that a plain JSON.stringify(error) dropped.
  • New shared exports from @paid-tw/einvoice: parseInput, parseTaipeiDate, taipeiDateTime, taxTypeToCode.

Under the hood (no API change)

  • Build migrated from tsup → tsdown (rolldown); published outputs unchanged, verified with attw + publint.
  • De-duplicated Taipei date helpers and the tax-type mapping into core.
  • Extracted types/wire-maps out of the large ECPay/ezReceipt providers.
  • Added MSW coverage for the tax-type wire mapping and the allowance amount guard.

All changes verified against the live provider sandboxes (Amego, ECPay, ezPay, ezPay cross-border, ezReceipt).

Versions

Package Version
@paid-tw/einvoice 0.3.2
@paid-tw/einvoice-amego 0.3.2
@paid-tw/einvoice-ecpay 0.3.2
@paid-tw/einvoice-ezpay 0.3.2
@paid-tw/einvoice-ezpay-crossborder 0.1.3
@paid-tw/einvoice-ezreceipt 0.1.3
Assets 2
Loading