Laravel Myanmar Tools Laravel Package

Getting Started

composer require pyaesoneaung/laravel-myanmar-tools

Laravel's package auto-discovery registers the service provider; there is nothing to publish for a first look. Read the source before the README — the repo is small enough to skim in ten minutes and is the only authoritative reference for exact rule names and helper signatures:

1. src/ — entry points (service provider, facade, helpers).
2. src/Rules/ — custom validation rule objects; this is where most day-to-day value lives.
3. config/ — only if present; otherwise defaults are hard-coded and you have no override surface.
4. tests/ — the fastest way to learn intended usage; copy the test cases into your own feature tests.

The first use case to wire up is form validation on a signup/profile form: a Myanmar phone number and (if you collect it) an NRC number. Put those rules in a FormRequest rather than in a controller so they are reusable:

class StoreProfileRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'phone' => ['required', 'string', new MyanmarPhoneNumber()],
            'nrc'   => ['nullable', 'string', new NrcNumber()],
        ];
    }
}

Verify the constructor signature against the actual source — treat the names above as placeholders and adjust.

Implementation Patterns

Rules as objects, not string rules. The package ships rule classes, not Validator::extend string aliases. That is a feature: keep using rule objects so you get typed constructors, per-rule messages, and the ability to unit-test them directly ((new MyanmarPhoneNumber)->passes('phone', '09...')).

Normalize on write, format on read. The most valuable pattern with Myanmar data is to store a single canonical form (Unicode text, E.164 phone numbers, structured NRC) and convert only at the edges. Wrap the package in a thin application-level service so that a future package swap or an abandoned dependency doesn't ripple through your codebase:

final class MyanmarText
{
    public static function toUnicode(string $value): string { /* package call */ }
    public static function isZawgyi(string $value): bool { /* package call */ }
}

Then call MyanmarText:: from casts, resources, and imports — never the vendor namespace directly.

Custom casts for text columns. If the package exposes Zawgyi/Unicode detection or conversion, hide it behind an Eloquent cast so models are always Unicode in memory and Zawgyi only ever exists at the integration boundary (legacy imports, copy-pasted user input, old SMS gateways):

protected function casts(): array
{
    return ['name' => UnicodeText::class];
}

API resources for presentation. Format currency (Ks), dates, and phone numbers in JsonResource classes rather than in Blade views, so web and mobile clients share one representation.

Blade directives sparingly. A @myanmarDate-style directive is convenient but invisible to static analysis. Prefer a helper or a resource method; reserve directives for truly view-only formatting.

Import pipelines. If the package offers transliteration, run it as an explicit import step (a queued job or an artisan command) rather than as a model mutator. Mutators silently rewrite history on every save, which makes debugging data corruption painful.

Testing. Add rules to your feature tests for valid and invalid fixtures (09xxxxxxxxx, +95xxxxxxxxx, malformed NRC). Snapshot a handful of known-good conversions so a package upgrade that changes behavior fails loudly.

Gotchas and Tips

Zawgyi/Unicode is the real risk, and it is not solvable by regex alone. Auto-detection heuristics produce false positives on short strings (single words, names with no stacked consonants). Never auto-convert destructive fields like legal names on save without an escape hatch — store the raw input alongside the normalized value, and let a human correct outliers.

Myanmar phone prefixes are genuinely inconsistent. 09…, +959…, 959…, and +95 9 … all appear in production data. Decide whether your rule accepts all of them and whether you normalize to E.164 before persisting. A validator that accepts +95 in one form and rejects it in another is a support ticket generator; test all four forms explicitly.

NRC numbers vary by state/division and by era. Township codes and the old/new format differ, and the "naing" digit encodes citizenship status. If the package validates format only, do not treat a pass as proof of a real NRC — layer your own business rules on top if you need that.

Timezone math. Myanmar is UTC+06:30 — a half-hour offset. Set config/app.php to Asia/Yangon for the app (or a dedicated myanmar connection config) and never do +6 hours arithmetic by hand. Half-hour offsets break naive strtotime assumptions and some date libraries' DST tables.

Database collation. Use utf8mb4 with utf8mb4_unicode_ci. Myanmar text in utf8mb3 or binary collations will sort incorrectly and can truncate. Also check that any LIKE search over Myanmar names behaves as users expect — collation determines whether ိ and ီ compare equal.

Vendor risk is real here. 29 stars, zero known dependents, and a tiny surface area. Pin the exact version in composer.json and read the changelog on every bump. For anything load-bearing (legal-name handling, payment forms), consider vendoring the handful of functions you actually use under your own namespace — the code is small enough that copying is cheaper than an outage.

Version compatibility. Confirm the package's Laravel and PHP constraints against your matrix before adopting, particularly on PHP 8.2+ where dynamic properties and implicit nullable parameters now warn. If you maintain multiple Laravel versions, run the rules through your CI matrix, not just local dev.

Extension points are limited. Without a published config file there is little to override. If you need custom error messages, define them in lang/*/validation.php keyed to the rule's message key, or subclass the rule and override message(). If you need different accepted formats, write your own rule and delegate to the package — don't fork it.

Debugging. Rule failures are silent by default; dump $validator->errors()->all() in a tinker session with your failing sample before assuming the package is wrong. Most "false negatives" are trailing whitespace, Arabic-Indic digits, or Zawgyi input that looks correct in the browser but differs at the byte level (bin2hex the string to check).

Don't expose raw package exceptions to users. Wrap calls in your adapter service and translate to domain exceptions, so replacing the dependency never changes your HTTP error codes.