Number Plus Laravel Package

Technical Evaluation

Architecture fit. masoudi/number-plus is a Laravel Nova field package, not a general-purpose PHP library. It occupies the narrowest possible slot in the architecture: a custom form control registered inside a Nova Resource's fields() method, backed by a compiled Vue component and a PHP field class extending Nova's Number field. It has no bearing on domain logic, persistence, APIs, or queue behavior. That means it is only architecturally relevant if the platform already runs Laravel Nova — a paid, proprietary admin panel — and only for the specific UX of an enhanced numeric input (increment/decrement controls, step/min/max enforcement, formatting). If the roadmap includes moving off Nova, building a custom admin UI, or exposing the same fields through an API, this package contributes nothing and becomes dead weight.

Integration feasibility. Mechanically trivial: composer require, register the field in a resource, done. The friction is entirely non-mechanical. The repository is archived, the last release is May 2023, and it carries a single star with zero dependents — meaning no downstream project has ever validated it in production. Nova's field API and asset pipeline changed materially across major versions (Nova 4's Vite-era asset handling, Nova 5's Vue 3 migration), so a 2023-era field has a high probability of failing to compile or render against a current Nova install. There is also no signal on whether the compiled JS bundle is checked in or built from source, which determines whether a fork is even viable.

Technical risk. This is a high-risk, low-reward dependency:

• Abandonment risk: certain. Archived means no security patches, no Nova 5 compatibility, no PHP 8.3+ fixes, no maintainer response. The risk is not probabilistic; it is realized.
• Supply-chain surface. A Nova field ships JavaScript that executes in an authenticated admin session. An unmaintained, single-author, near-zero-audience package running in the highest-privilege UI in the app is a poor trade for a number input.
• Version-coupling risk. Nova is itself versioned and licensed, so the compatibility matrix is a two-dimensional problem (package × Nova major × PHP × Laravel) with no maintainer to resolve conflicts.
• Bus factor: one, and that one has signaled exit by archiving.

Key questions.

1. Which Nova major versions does the composer.json constraint actually permit, and has anyone verified rendering on our Nova version?
2. Is the Vue source present and buildable, or is this a pre-compiled bundle we cannot audit or patch?
3. What does the field do that Nova's native Number field with min, max, step, and displayUsing cannot already do?
4. What is the license, and does it permit vendoring into a private repo?
5. Are there known CVEs or outdated transitive JS dependencies in the asset bundle?

Integration Approach

Stack fit. Only viable for teams already licensed and running Nova. The value proposition is purely presentational — better numeric input ergonomics in an admin panel — so it belongs in the "internal tooling polish" bucket, never in a revenue-critical path. If the product's admin surface is a competitive differentiator and Nova is the long-term bet, a numeric input enhancement is a legitimate want; if Nova is incidental glue, this package is not worth the conversation.

Migration path. Do not adopt as a live dependency. Instead, treat the repository as a reference implementation: vendor the field class and Vue component into an internal app/Nova/Fields namespace, take ownership of the build, and re-verify against the current Nova version. If the source bundle is unavailable or unbuildable, fall back to Nova's native Number field and accept the UX delta; that is the correct default and the cheapest option.

Compatibility. Before any code moves, build a small compatibility matrix: package version × Nova major × PHP version × Laravel version. Given the May 2023 release date, assume Nova 3/4 only until proven otherwise, and assume no PHP 8.3+ guarantees. Any mismatch on the Nova major is a hard stop for direct adoption and pushes you to the vendor-and-port path.

Sequencing.

1. Spike (hours, not days): install in a disposable Nova sandbox, render one field, confirm the asset pipeline works on our actual Nova version.
2. Decide: if the spike fails, stop — native Number field, close the ticket. If it passes, proceed only via vendoring.
3. Vendor: copy source into the codebase, add a smoke test that the field registers and the component mounts, wire into one low-traffic resource.
4. Expand: roll out to remaining resources only after a Nova upgrade cycle has been survived once.

Operational Impact

Maintenance. Ongoing maintenance is a certainty and it lands on us, not a vendor. Budget for a Nova-major upgrade review every cycle: re-checking the field against Nova's field API, re-building assets, and confirming the Vue component still mounts. Small surface, but permanently owned. The archived status converts a "dependency update" into "internal code we maintain."

Support. No upstream support channel, no issue triage, no security advisory feed. Internal developers become the escalation path. Document the vendored code's origin, license, and the reason it exists, or it will be deleted by a future cleanup and re-litigated.

Scaling. Negligible. A form field is a per-request, per-render UI concern with no throughput, storage, or concurrency implications. It will not be a bottleneck at any realistic admin-panel scale. The scaling risk is organizational — number of engineers who understand the vendored component — not technical.

Failure modes.

• Silent render failure after a Nova or asset-pipeline upgrade: field appears blank or throws a JS error on the resource form, blocking admin edits. Highest-likelihood failure.
• Unpatched JS dependency in the compiled bundle, exploitable by any actor who can reach an authenticated admin session.
• Version drift: composer update resolves a Nova version the vendored code cannot handle, discovered in production rather than CI.
• Source loss: repo archived, tarball unavailable or the source directory absent, making the fork unmaintainable.

Mitigate with a registration smoke test in CI and a pinned, committed copy of the source.

Ramp-up. Low for anyone fluent in Nova — a field class plus a Vue component is a well-trodden pattern, roughly a half-day for a mid-level Laravel engineer to read and modify. The real ramp-up cost is the discovery work: confirming which Nova versions it supports, whether the source is buildable, and what it duplicates from the native field. Budget a short spike to answer those, not a sprint.

Bottom line. Score and signals (one star, zero dependents, archived, no release in two years) describe a package with essentially no adoption evidence. For a numeric input in an admin panel, the correct TPM position is: do not take a live dependency — verify whether native Nova already covers the requirement, and if not, vendor the source under our ownership or build the field ourselves. The upside is cosmetic; the downside is an unmaintained JS artifact in the most privileged UI in the product.