- What does mad-web/nova-telescope-link actually do?
- It is a thin convenience package that adds a quick-access link to Laravel Telescope inside your Nova sidebar or tool menu. Clicking it deep-links into the Telescope dashboard, so you can move from admin screens to the debugger without manually typing /telescope. It does not touch domain logic, persistence, or the request lifecycle — it is purely a navigation seam between Nova and Telescope. Treat it as a toolchain appendix rather than an architectural dependency.
- How do I install nova-telescope-link in a Laravel Nova app?
- Run composer require mad-web/nova-telescope-link, then register the tool or menu entry inside the tools() method of your NovaServiceProvider. There are no migrations, no publishable assets of consequence, and no environment configuration surface to model. Because the source is very small, read it end to end before registering so you know exactly what the link renders and where it points.
- Which Nova and Laravel versions does this package support?
- You must check the composer.json constraints in the repository before adopting it, since the package pins specific Nova majors. Nova ships on a licensing cadence (4.x to 5.x), and a link package pinned to an older Nova constraint can silently block your upgrade path. Validate the full matrix yourself: PHP 8.1+, Laravel 10 or 11, Nova 4.x (and confirm 5.x), and Telescope 4.x or 5.x.
- Is it safe to expose a Telescope link in production?
- No, not by default. Telescope is a debugging surface that should be gated to local and staging environments, and a persistent Nova menu item invites clicks where Telescope may be disabled or, worse, reachable. The package cannot enforce that policy for you, so wrap the registration in an environment check such as app()->environment('local', 'staging') plus an explicit authorization callback. Also confirm Telescope's own gate is aligned with your Nova authorization model.
- Does the package respect Nova authorization callbacks like canSee or authorizedToSee?
- This is the key question to verify in the source, because the TPM evaluation flags an authorization gap: the link itself is just a URL rendered inside an authenticated admin context. If visibility is unconditional, users who should not see Telescope internals get a discoverable path to request and query data. Chain a canSee or authorizedToSee callback on the tool registration, and ensure Telescope's viewTelescope gate is at least as strict as your Nova permissions.
- Does nova-telescope-link force Telescope into production dependencies?
- Telescope is normally a require-dev package, and you should confirm the link package does not hard-require it in a way that expands your production footprint for a convenience feature. Ideally Nova and Telescope are declared as optional or peer-style dependencies so non-Nova services in a monorepo remain unaffected. Check composer.json before merging, and run composer why mad-web/nova-telescope-link if the dependency graph looks surprising.
- Can I change the Telescope path the link points to?
- The link targets a route name that Telescope already registers, so it usually follows whatever path Telescope exposes. Whether the package lets you override that value is something to confirm by reading the source and any config file it publishes. If it is hardcoded to /telescope and your app mounts the dashboard elsewhere, you are better off writing your own Nova menu entry with a configurable URL.
- What happens if Telescope is not installed or its route is disabled?
- The package should degrade gracefully, but verify it in a branch where Telescope is removed or its route is gated off. A link that resolves to a route name which does not exist can throw at render time or leave a dead menu item in the sidebar. Conditionally register the tool only when Telescope is installed and the route is available.
- Is nova-telescope-link maintained, or should I build the link myself?
- Adoption risk here is governance rather than code: the repository has essentially no stars, dependents, or release history, so breakage will not surface through a consumer base. The entire value proposition is roughly twenty lines of a custom Nova::menu or tool registration, making vendor risk asymmetric against a near-zero build cost. Most teams should spike by auditing the source, then replicate it in-house with environment gating and an authorization callback.
- How do I test or roll back the Telescope link in a Nova app?
- Install with Composer, register the tool behind an environment check, then load the Nova dashboard in local and staging to confirm the menu entry appears and the link resolves to a working Telescope route. Rollback is a single commit: run composer remove mad-web/nova-telescope-link and delete the registration line, with no schema, data, or cache implications. Add a feature test asserting the tool is absent in production-like environments so the gate cannot silently regress.