Laravel Nova Vapor Ui Link Laravel Package

Getting Started

• composer require fidum/laravel-nova-vapor-ui-link — the package is a thin Nova integration (a sidebar link/tool that deep-links from your Nova dashboard into the Laravel Vapor UI for a given project), so there is very little surface area to learn.

• Look first at the package's published config (config/vapor-ui-link.php or similar under vendor/fidum/laravel-nova-vapor-ui-link/) and its service provider — that is where the Vapor project identifier and URL are resolved. The whole package is smaller than most Nova tools, so reading the source is faster than the README.

• Publish the config and set the project identifier in .env:

  php artisan vendor:publish --tag=vapor-ui-link-config
  

  VAPOR_UI_PROJECT_ID=your-vapor-project-id
  

• Register the tool/menu entry in app/Providers/NovaServiceProvider.php (tools() for Nova 3.x tool-style registration, or the menu API if you're on a Nova version that exposes one). Then php artisan config:clear and reload /nova.

• First real use case: an operator is paged about a slow queue or a failed deploy, opens Nova to check the admin panel, and uses the link to jump straight to that project's Vapor UI deployments/logs instead of navigating the Vapor dashboard by hand.

Implementation Patterns

• Environment-driven project mapping. Keep the Vapor project id in config, sourced from env. For multi-environment apps (staging + production deployments of the same codebase), map environment → project id in the config file rather than hardcoding a single id:

  'project' => env('VAPOR_UI_PROJECT_ID', [
      'production' => 'my-app-prod',
      'staging'    => 'my-app-staging',
  ][app()->environment()] ?? null),
  

• Gate the link to the environments that have a Vapor UI. Locally there is no Vapor project; conditionally registering the tool (or returning false from a canSee callback) keeps the sidebar honest and avoids dead links for developers running the app on their machines.

• Restrict visibility to operators. Infrastructure links are noise for most Nova users. Wrap registration in an authorization check (Gate, $user->isAdmin(), or Nova's canSee) so only the people who actually act on Vapor see the entry.

• Version alignment is part of install. 1.0.2 targets Vapor UI ^1.0. Treat the package version and your team's Vapor UI version as a pair; record the pairing in your upgrade notes so the next composer update doesn't silently produce links to an old URL scheme.

• Treat it as a one-line integration, not a layer. Because the package only builds a URL, resist the urge to wrap it in your own abstraction — configure it, register it, and move on. If you need extra behaviour (branch filter, per-user projects), build the URL in your own Nova tool rather than forking this one.

Gotchas and Tips

• 1.0.2 is a URL-scheme change, not just a dependency bump. The release adds support for Vapor UI ^1.0, which almost certainly means the generated link/URL pattern was updated. If any of your apps or teams are still on a legacy Vapor UI, pin 1.0.1 explicitly — ^1.0.2 will give you links that 404 or land on the wrong page.
• Config is cached. After changing VAPOR_UI_PROJECT_ID (or the environment mapping) run php artisan config:clear — or config:cache on deploy. A stale cached config is the most common reason "the link still points at the old project."
• Link missing entirely? Check, in order: (1) php artisan package:discover / composer dump-autoload ran after install, (2) the provider is not disabled in bootstrap/cache/packages.php, (3) the tool is actually registered in NovaServiceProvider, (4) your canSee/gate isn't returning false for your user.
• Nova asset publishing. If the package ships any Nova assets, php artisan nova:publish is required after upgrade; a stale public/vendor/... manifest is a classic "I upgraded but nothing changed" trap.
• Sidebar ordering. Position in the tools() array controls menu order. Put the Vapor link near the bottom so it doesn't displace day-to-day resources.
• Extension points are thin by design. The config file plus the URL-building method are the only knobs. If you need query-string parameters (branch, environment tab), override the config or build the link yourself — don't expect hooks that aren't there.
• Low-traffic package. Small maintainer, no visible test suite in the release notes. Pin via composer.lock, and read the diff of any future release before deploying — a URL-format change like this one is exactly the kind of thing that fails silently in production rather than in CI.