Kurdish Escpos Laravel Package

Product Decisions This Supports

Vendor and dependency decisions for Kurdish/Arabic-script receipt printing. This package occupies a narrow but real niche: ESC/POS thermal receipt output where the text is Kurdish (Sorani) or otherwise Arabic-script, which requires bidi handling and letter shaping that generic ESC/POS libraries do not do. That makes it a candidate for any feature involving printed receipts, invoices, kitchen tickets, or delivery slips in Kurdish-speaking markets (Iraq/KRI, and diaspora-facing businesses).

Build vs. buy tilts toward "buy" (adopt), with caveats. Rolling your own Arabic-script ESC/POS renderer means implementing contextual glyph shaping, lam-alef ligatures, RTL line layout, and codepage/bitmap-font fallbacks — weeks of work with a long tail of edge cases that only surface in production printouts. Reusing a focused package is usually the cheaper path, provided the maintenance risk below is acceptable.

Roadmap implications. If Kurdish-language receipts are on the roadmap, this is an enabler and should be scheduled as a spike, not a commitment. If Kurdish receipts are already shipped or promised to a customer, this release is a forcing function: any environment pinned to ^0.1–^0.5.0 cannot install from Packagist as of this release. That is a live build-break risk in CI and on new machine provisioning, and it should be triaged as a maintenance task regardless of whether you adopt the package.

Pre-1.0 status is itself a product signal. The version is 0.5.1; the API is explicitly unstable, and this release demonstrates that the project is still reshaping its own history. Do not build a public or contractual integration on it without an internal wrapper/facade so an upstream rewrite does not leak into your domain code.

When to Consider This Package

Adopt (or trial) when all of the following hold:

• You need Kurdish or Arabic-script text on ESC/POS thermal printers — this is the package's reason to exist; for Latin-only receipts it offers nothing over mature alternatives.
• Your stack is Laravel/PHP and you are comfortable with a Composer dependency in the print path.
• You can pin to a floating minor constraint (^0.5) or a locked commit, and you accept that patches may occasionally be non-semantic (this one was a pure re-publish).
• You have a hardware test path — real printer models and paper widths. Script shaping and codepage selection fail in ways that unit tests will not catch.
• The printing volume/risk is internal-facing (kitchen tickets, order slips) rather than legally regulated output (tax invoices with mandated formats).

Look elsewhere, or hold, when:

• Maintenance risk is unacceptable. A single-maintainer, pre-1.0 package with a rewritten git history is not a safe dependency for a multi-year, mission-critical print pipeline. Consider mike42/escpos-php (broad, mature, but no script shaping) plus your own shaping layer, or an OS-level driver/CUPS route where the OS handles fonts and bidi.
• You need guaranteed reproducibility. Versions 0.1.0–0.5.0 are now uninstallable from Packagist. If your CI, Docker images, or composer.lock reference those constraints, builds will fail. You must either upgrade to ^0.5.1 or vendor the code into your repository.
• Non-Kurdish receipts are the only requirement — use the established ecosystem instead.
• You need SLA-grade support, vendor indemnity, or a security disclosure process. None of that is evident here.

Immediate action for anyone already on it: raise the constraint to ^0.5.1, regenerate composer.lock, and add a lockfile-integrity check to CI. Treat the re-publish as a supply-chain hygiene lesson: for any pre-1.0 dependency, mirror or vendor the artifact you actually shipped.

How to Pitch It (Stakeholders)

For executives: We are evaluating a small open-source PHP component that lets our system print receipts in Kurdish. Without it, Kurdish receipts render as garbled or disconnected characters — a visible quality problem in Kurdish-speaking markets. The component removes roughly several weeks of specialist work we would otherwise absorb ourselves. The trade-off is counterparty risk: it is a young, single-maintainer project at version 0.5, so the recommendation is to adopt it behind an internal abstraction layer for internal-facing printing (order slips, kitchen tickets) first, and only extend it to customer-facing or legally-regulated documents after a measured trial.

For engineering: This is rawand201/kurdish-escpos v0.5.1 — functionally identical to 0.5.0, re-published because the upstream git history was rewritten and Packagist pins versions to their original commits, making 0.1.0–0.5.0 uninstallable. Two consequences: (1) migrate any existing constraint to ^0.5.1 and re-lock, or vendor the source; (2) wrap the package behind our own printing interface so the pre-1.0 API cannot penetrate domain code. Integration is straightforward on Laravel, but validation must happen against real printer hardware across the target models and paper widths — bidi/shaping bugs are only observable on paper. Budget a short spike before any roadmap commitment.

Ask: Approve a two-day spike — hardware validation plus a wrapper interface — and a one-line dependency bump to ^0.5.1 in any affected service.