Wm Package Laravel Package

Technical Evaluation

Architecture fit. The v1.5.0 changelog resolves the central unknown from the prior assessment: wm/wm-package is not a helper library or metapackage, it is a full geospatial domain module. It ships Eloquent models (EcTrack, EcPoi, FeatureCollection) with relations, migrations, observers, queued jobs, Nova resources, services (FeatureCollectionService, GeometryComputationService, PBFGeneratorService), Excel import/export, taxonomy sync, and Vue frontend components (FeatureCollectionMap, ApiLinksCard, AppTiles, slope chart) with their own Vitest suite. Fit is now sharply bimodal: high if we are building an Italian-market outdoor/hiking/trail platform on Laravel + Nova, near-zero otherwise. The CAI tile configuration (Club Alpino Italiano) and EN/IT-only localization confirm the intended domain is narrow and specific.

Integration feasibility. Mechanically still composer require, practically a different proposition. Adoption now implies accepting a data model, database tables, queue topology, storage layout, Nova admin surface, and a frontend asset pipeline. That is not a dependency decision, it is a bounded-context adoption decision. Feasibility hinges on questions the changelog cannot answer: Nova major version, Laravel/PHP constraints, whether migrations are publishable and namespaced, and whether the package expects to own tables we already own.

Technical risk. High, but the risk profile has changed from "abandoned utility" to "deep coupling with a single-vendor domain module." Newly visible risks: a hard dependency on Laravel Nova (paid, licensed per-seat, historically breaking between majors); a likely Excel dependency (PhpSpreadsheet/Maatwebsite) that is heavy and version-sensitive; Scout indexing (ReindexAppScoutAction) implying an external search engine; file storage for generated GeoJSON; and a PBF generation path that probably requires binary/system tooling. Semver discipline is also a concern — the removal of the legacy import command is an API-surface removal shipped inside a minor bump. The 2026-04-30 date remains anomalous and should still be treated as a metadata artifact; the unusually large single-release delta suggests either a long gap since v1.4.0 or squashed/semantic-release-generated history, either of which weakens our ability to reason about upgrade risk.

Key questions.

• Does the package own EcTrack/EcPoi/FeatureCollection tables outright, and are its migrations safe to run alongside an existing schema?
• Which Nova major version, and are we prepared to license and upgrade Nova in lockstep?
• What are the PHP, illuminate/*, Scout, storage, and Excel dependency constraints, and is there a CI matrix?
• What infrastructure does PBFGeneratorService need at runtime (system binaries, memory, CPU)?
• How do the observers and GenerateFeatureCollectionJob scale — is regeneration debounced, or does every taxonomy edit fan out into a rebuild?
• Are the Vue components published as build artifacts or source, and do they assume Vite and a specific Inertia/Livewire host?
• What is the intended multi-tenancy model behind app_id filtering and AppConfigService?
• Is there any support relationship with Webmapp, or is this strictly self-support?

Integration Approach

Stack fit. Now a narrow gate. Requires Laravel + Laravel Nova + a queue worker + object/file storage + (probably) Scout + a Vite frontend. If any of those are absent or we are on a different admin stack (Filament, custom), the package is unusable without forking out large sections. If we are not in the outdoor/trail/POI domain, the models and taxonomy are dead weight.

Migration path. Still greenfield in the sense that we are not migrating off anything, but adoption is no longer a drop-in. The realistic options are: (a) adopt as a dependency in a dedicated Laravel service where the package's data model is the system of record; (b) fork and vendor into packages/ and accept ownership of ~a domain module's worth of code; (c) harvest specific, self-contained pieces (geometry handling, GeoJSON/PBF export, slope chart, import/export) into our own code. Option (c) is likely the best value-per-risk for a team that is adjacent-but-not-identical to Webmapp's domain. Option (a) is only defensible if we are essentially building the same product.

Compatibility. Verify by inspection: composer.json PHP and illuminate/* constraints, the Nova constraint, extra.laravel providers, published migrations and their table names, published config keys, route prefixes, queue names, and the asset build setup (vite.config, package.json). Confirm whether migrations are idempotent and namespaced, and whether the frontend ships compiled or requires our build. Check the Vitest setup as the only visible test signal; backend test coverage is unknown.

Sequencing.

1. Source audit — composer.json, service provider, migrations, config, routes, package.json, tests/CI. Budget 1–2 days now, not half a day.
2. Collision analysis — model names, table names, config keys, route prefixes, queue names against our schema.
3. Dependency and license review — Nova seats, Excel library, Scout driver, storage, PBF tooling.
4. Timeboxed spike in a throwaway Laravel + Nova app: import a track, generate a feature collection, render the map, run a taxonomy change and watch the observer/job chain.
5. Decide: adopt as a service, fork and vendor, or extract components.
6. If adopted, isolate behind internal interfaces at the model and service boundaries, and pin to a commit SHA rather than a tag.
7. Register in the dependency inventory with an owner, an upgrade runbook, and a review date tied to Laravel and Nova majors.

Operational Impact

Maintenance. We inherit a domain module, not a utility. Every Laravel major, every Nova major, every PHP minor, and every shift in the Excel/Scout/storage ecosystem is now our problem, and there is no upstream test matrix in evidence. Budget ongoing capacity, not a one-off review.

Support. No community, no published docs, no dependents. Commit messages reference internal tickets (OC:6075, OC:7283, OC:7739), which is the clearest possible signal that the roadmap is driven by one company's product backlog. Plan for self-support and treat upstream as a reference implementation.

Scaling. Runtime cost is now material and must be measured, not assumed. GenerateFeatureCollectionJob and the layer/taxonomy observers mean a single content edit can trigger regeneration and storage writes; without debouncing this becomes a thundering-herd pattern under bulk imports. PBF generation is CPU- and memory-intensive and probably the heaviest operation in the system. Generated GeoJSON accumulates in storage and needs a retention policy. Excel import of large track/POI files is a classic memory and timeout failure point. The Nova admin surface adds query load on taxonomy and order-list operations.

Failure modes.

• Migration or model-name collision with our existing schema; migrations that assume they own the database.
• Nova major upgrade breaking the admin surface with no upstream compatibility guarantee.
• Silent removal of further public surface in minor releases (the legacy import command removal is precedent).
• Storage failure during GeoJSON generation (the release adds an exception path here, which is a good sign but implies the failure mode is real).
• Geometry edge cases — complex/point geometry support and slope-chart coordinate handling were both being fixed in this same release, so that code path is still settling.
• Queue backpressure and worker starvation from observer-triggered regeneration during bulk edits.
• PBF toolchain breaking on a base-image or PHP upgrade.
• Frontend asset pipeline drift — Vitest was introduced in this release, so the JS side is actively churning.
• Future-dated or irregular tagging making version pinning unreliable; pin to a commit SHA.

Ramp-up. Substantially higher than previously assessed. The conceptual surface now includes tracks, POIs, taxonomy, layers, feature collections, app configuration, PBF output, and a Nova admin model. A mid-level Laravel engineer needs to learn the domain before being productive. Estimate one to two weeks to competence for a capable engineer, longer if we fork and must own the PBF and import/export paths. Documentation will have to be written by us; upstream will not supply it.

Bottom line for a TPM. v1.5.0 changes the verdict from "ignore unless curious" to "evaluate as a build-vs-adopt decision for a geospatial bounded context." This is a real, actively developed domain module — the velocity is genuine and the scope is large — but it is also single-vendor, undocumented, Nova-coupled, infrastructure-hungry, and semver-loose. If we are building an Italian outdoor/trail platform on Laravel + Nova, a spike is warranted and the fork-and-own path may be legitimate. If we are not, the correct move is to harvest the geometry and export logic, not to composer require. Either way, the prior conclusion holds in spirit: treat it as an internal artifact that happens to be public. The release does not change adoption signals — there is still no ecosystem around it — it only clarifies how much code we would be taking on.