- Does mydnic/nova-kustomer work with Laravel Nova 4 or Nova 5?
- Almost certainly not without modification. The package was published in December 2019, putting it in the Nova 2/3 era with a webpack/Mix asset pipeline, Vue 2 components, and composer.json constraints aimed at Laravel 5.8–6.x and PHP 7.x. Nova 4 moved to Vite and Vue 3, and Nova 5 requires PHP 8.2+, so the Composer resolver will likely block the install before you even discover whether the compiled JS entry mounts.
- How do I install mydnic/nova-kustomer?
- The documented path is a composer require, registering the package's ToolServiceProvider, publishing the config file, and setting a Kustomer API key. On a modern Laravel/Nova stack you should treat this as a timeboxed spike rather than an installation plan, because Composer platform constraints and the Vue 2 front end are both expected to break. Verify the package's composer.json requirements against your pinned PHP and Nova versions before committing to anything.
- Is mydnic/nova-kustomer still maintained?
- No. There have been no releases in roughly six years, it has a single maintainer, around 18 stars, zero dependents, and a health score of 0.09. That means there is no community canary—you would be the only team exercising this code in production. Budget for owning any fixes yourself.
- How does the package handle the Kustomer API key, and is it secure?
- The tool talks to the Kustomer REST API, which holds customer PII, so the key handling is the critical thing to audit. You must confirm the key is only used server-side and is never serialized into the Nova payload or exposed to the browser—a browser-side API call with the key would be a hard stop. There is no upstream security disclosure path, so review the Vue view and the server-side calls yourself before production use.
- What Kustomer data can agents actually see inside the Nova panel?
- The intended surface is customer profiles, conversation history, and surrounding support context, rendered in a Nova menu entry alongside your own models such as orders, accounts, and tenants. Read-only display is a small build; write-back features like posting notes or applying tags multiply the scope considerably. Decide which of those your agents actually need before evaluating the package further.
- Should I fork mydnic/nova-kustomer or rebuild it as a Nova Card?
- Fork only if the diff stays under roughly two to three days: bump composer.json to php ^8.2, laravel/framework ^11, and laravel/nova ^5, replace the Mix build with Vite, port the Vue 2 components to Vue 3, and re-register the tool in NovaServiceProvider::tools(). The default recommendation is a rebuild: a Nova Card backed by a small KustomerClient service class with caching and rate-limit handling. The required surface area is small, the result is maintainable, and it removes the abandoned-dependency flag entirely.
- What are the alternatives to embedding Kustomer inside Laravel Nova?
- Kustomer's native embeddable widget, its Slack, Salesforce, or Shopify integrations, a generic API card, or simply a link-out to Kustomer's own inbox may cover most of the need with zero owned code. If your support team does not already work in Nova, or you do not need Kustomer context next to your own models, a link-out is the better design. Evaluate those before accepting the maintenance burden of a package.
- What breaks first when running this package on a current Laravel stack?
- Expect failure at three seams: Composer platform constraints, the deprecated Mix asset pipeline versus Vite, and Vue 2 components that will not mount in a Vue 3 Nova. Kustomer's own API surface has also evolved, and the vendor has changed ownership, so JSON parsing can break silently with no upstream patch coming. Each of those is independent, so a partial fix does not get you to a working tool.
- Does nova-kustomer call the Kustomer API from the server or from the browser?
- The architecture is a thin presentation-layer plugin—a Vue view plus server-side calls to the Kustomer REST API—but you must confirm that with your own audit. If any API call is made from the browser with a key embedded in the payload, treat it as a hard stop and do not deploy. Server-side only, with the key read from config, is the acceptable shape.
- Will this package show up in composer audit or Dependabot as an abandoned dependency?
- Yes. A package with no release in six years, a single maintainer, and zero dependents will typically be flagged as abandoned or unmaintained, and a 0.09 health score with an "opportunity" signal of 13.84 means cheap to replace, not cheap to adopt. Nothing else in your system should depend on it, since it is a convenience affordance rather than infrastructure. Rebuilding it as a small in-house Nova Card drops the flag from audit entirely.