Laravel Map Laravel Package

Technical Evaluation

Assessment posture: The package is archived, has 4 stars, and its last release was 2021-12-28. That is the dominant fact in this evaluation. Everything else — a tidy Blade API for plotting Eloquent models on a Leaflet map, a config file, publishable assets — is table stakes that a mid-level Laravel developer can reproduce in a day or two. We are not evaluating whether the package works; we are evaluating whether a thin, unmaintained wrapper around Leaflet is worth the supply-chain line item.

Architecture fit: The package assumes Laravel + Blade with server-rendered map views and a bundled Leaflet build. That fits an admin console, a store locator, or an internal dashboard where the map is decorative rather than load-bearing. It does not fit an Inertia/React or heavily Livewire-driven surface, where the package degrades to "a config array plus a JS bundle we didn't write" and the Leaflet integration has to be re-done by hand anyway. The fetch methode added in v1.0.6 signals an intent to support post-load data, but an unmaintained package shipping an undocumented data-loading path in 2021 is not a foundation we should build dynamic maps on.

Integration feasibility: Mechanically simple — composer require, vendor:publish, render a component. The work is not integration effort; it's diligence effort. The v1.0.6 note psr-4 name implies a namespace change shipped in a patch release, which is a semver-hygiene failure and the single most likely source of a boot-time Class not found in any consumer. Because the project is archived, there will never be an upstream fix, upgrade note, or compatibility patch for future Laravel or PHP majors.

Technical risk:

• Maintenance risk (high, certain). Archived status means no security patches, no Leaflet updates, no PHP 8.x/Laravel 11+ compatibility work. The bundled Leaflet will age into known-vulnerable territory; the composer constraints will eventually block a framework upgrade. This risk is realized on a schedule, not probabilistically.
• Supply-chain risk (medium). A 4-star, single-maintainer, archived package is a low-scrutiny dependency. We should assume no test suite, no CI, and no security review by anyone but us.
• Namespace/PSR-4 risk (medium, bounded). Only relevant if we adopt the package and later bump; if we vendor a snapshot, it's a one-time audit.
• Unknown fetch contract (medium). Error handling, abort, CSRF, auth scoping, and response shape are all undocumented. Any dynamic-map work depends on reverse-engineering it — cost that lands on us, not the maintainer.
• Opportunity cost (high). The package's entire value is saving roughly one to three days of Leaflet wiring. That saving is smaller than the cost of the governance conversation this dependency requires.

Key questions:

1. Is the map surface load-bearing (revenue, operational decision-making, customer-facing) or decorative? Decorative surfaces tolerate a frozen dependency; load-bearing ones do not.
2. Do we need the package at all, or does Leaflet plus a ~100-line Blade partial and a JSON endpoint meet the requirement? Given archived status, "build" is now the lower-risk path for anything beyond a prototype.
3. If we adopt anyway, do we vendor a pinned snapshot into app/ or a private fork, transferring ownership in-house? Adopting the public repo as-is is not defensible.
4. Which Leaflet version is vendored, and does it carry known CVEs? This is the only genuinely urgent question for a security review.
5. What is the licensing? (Unverified — must confirm before vendoring.)
6. What PHP/Laravel matrix does it support, and does that survive our next framework upgrade cycle?
7. Does any existing app already depend on this? If so, this becomes a remediation project, not an adoption decision.

Integration Approach

Recommendation: Do not take a production dependency on bagusindrayana/laravel-map. Treat it as a reference implementation: read the Blade component and config to confirm the shape, then build the equivalent in-house (~1–3 days) or vendor a pinned snapshot under our own namespace if we need to keep existing behavior during a migration. This reframes the work from "integrate a package" to "retire or absorb a small piece of code," which is a far easier approval.

Stack fit and decision matrix:

• Prototype / internal spike: Adopt directly with a pin. Acceptable, time-boxed, no production exposure.
• Blade-rendered production surface: Build in-house on Leaflet. The package saves days and costs a permanent unowned dependency.
• Inertia / SPA / Livewire: Skip the package entirely; the server-side component model does not carry over.
• Already integrated somewhere: Vendor a snapshot and schedule the in-house replacement.

Migration path (if currently on the package, or if adopting the snapshot):

1. Pin the exact version and vendor the source into our own namespace; record the provenance (commit SHA, date, license) in the repo.
2. Diff composer.json autoload and the namespace layout before anything else — the psr-4 name change in v1.0.6 is the top breakage candidate.
3. grep -r the codebase for the old namespace, facade aliases, config key prefix, and any Blade directive the package registers.
4. Re-publish assets with --force and add cache-busting/asset versioning so browsers do not serve stale Leaflet/JS after deploy.
5. Smoke-test the full path: map renders, tiles load, existing markers intact, the fetch route exercised against both an authenticated and an unauthenticated request.
6. For the in-house replacement: extract the config (center, zoom, tile provider, key) into config/maps.php, keep the JSON endpoint contract stable (lat, lng, label, optional meta), and swap the view layer behind the same route names so consumers don't change.

Compatibility: Confirm PHP/Laravel constraints against our runtime; check for a second Leaflet instance elsewhere (double-loading is a classic silent breakage); decide between published vendor assets and our own Vite bundle — never both. Tile provider API keys belong in env/config, not in published JS.

Sequencing: (1) Inventory — find every reference to the package and confirm whether anything in production depends on it; half a day, and it gates the rest. (2) Security read — vendored Leaflet version and CVEs; half a day. (3) Decide build-vs-vendor based on step 1's blast radius. (4) If retiring, replace behind the same routes and endpoint shape, one surface at a time. Do not combine a namespace/asset upgrade with a fetch adoption in a single release.

Operational Impact

Maintenance: If adopted as a live dependency, the burden is not steady-state — it's the guaranteed future event where a Laravel or PHP upgrade breaks it and no upstream fix exists. Archived dependencies convert routine framework upgrades into small migration projects. That cost is invisible on the day of adoption and lands on whichever team owns the app 18–24 months later. Vendoring solves the supply-chain problem and moves the code into our normal review and test hygiene, which is the right trade for a component this small.

Support: There is no support path. Single maintainer, archived, no issue triage, no security disclosure channel. Any defect is ours to fix, and we should say so explicitly in the decision record rather than discovering it during an incident. Ownership must sit with the team that owns the map surface — never a shared platform team, which would create exactly the orphaned-dependency problem this package represents.

Scaling: Not a package-scaling question in the usual sense — Leaflet is client-side. Real limits are: tile-provider rate limits and API key quotas (fails as gray tiles, not an error); marker performance past a few thousand points without clustering; and the payload size and request cadence of the fetch path if it polls or ships GeoJSON. Cache slow-moving marker data server-side and set explicit cache headers.

Failure modes to monitor:

• Blank or unstyled map post-deploy — stale published assets, or Leaflet loaded twice.
• Class not found at boot if any code path still references the pre-v1.0.6 namespace (only relevant during a bump).
• Silent fetch failures — data simply never appears; there is no error UI by default. Instrument the console and add explicit empty/error states.
• CSRF 419s if the fetch path bypasses Laravel's token handling.
• Tile quota exhaustion or key rotation presenting as gray tiles rather than an alert.
• Browser-cached old JS paired with new server-rendered markup after release — requires asset versioning.

Ramp-up: Low, and that is part of the problem — a mid-level Laravel developer can pick this up in under a day, which is why it gets adopted casually and orphaned quietly. The fetch/JS layer plus the asset pipeline needs two to three days of real familiarity. Whoever owns it should also own a one-page runbook covering the two things that will bite the next person: re-publishing assets after any upgrade, and auditing the namespace on every bump.

Bottom line: For a prototype, use it and move on. For anything with a production lifetime, the archived status makes this a build-not-buy decision — the package saves days and costs an unowned dependency with no upgrade path, which is a poor trade for a wrapper this thin.