Launch Laravel Laravel Package

Getting Started

launch-laravel is pre-1.0 (v0.3.x), so treat minor bumps as potentially breaking and pin the version in composer.json until you've read the changelog.

1. Install and let package discovery register the service provider:

   composer require nckrtl/launch-laravel
   

2. Publish the package's config (and any publishable routes/views) before touching anything else:

   php artisan vendor:publish --provider="Nckrtl\Launch\LaunchServiceProvider"
   

3. Look at the package's routes/ directory first. As of v0.3.10 the package ships standard Laravel route files instead of registering routes through the Waymaker abstraction. That file is now the source of truth for which URIs and route names the package owns, what middleware they run through, and where you'd hook in overrides. Reading it answers most "why is this URL responding?" questions immediately.
4. First use case: boot the app, hit the route the package registers, and confirm it resolves through your normal web middleware group. Then write one feature test asserting the response so later route-file changes surface as test failures rather than 404s in production.

Implementation Patterns

Treat the package route files as the integration point. Because routing now goes through Laravel's native route loader, the usual Laravel mechanisms apply: route names, middleware, Route::domain(), route model binding, and route:list all behave as you'd expect. Verify with:

php artisan route:list --path=<package-prefix>

Ordering against your own routes. Package routes are typically loaded from the service provider's boot(). If your routes/web.php defines a catch-all or fallback (common in apps that want a custom landing page), make sure your route wins. Either register yours earlier, or gate the package's routes behind config so they don't register at all in environments where you've replaced them.

Override by configuration, not by editing vendor files. Prefer published config toggles for prefix/middleware/enabled-state. If the package exposes publishable route files, publish them and let the package skip its own copy — otherwise composer update silently reverts your edits.

Middleware composition. Put auth/tenant/throttle middleware around the package routes via config rather than duplicating the package's route definitions. This keeps you aligned with upstream when they add new routes.

Testing pattern. In tests/Feature, assert both the happy path and the "disabled" path (package routes not registered when the feature flag is off). This is the cheapest guard against routing regressions in a pre-1.0 dependency.

CI hygiene. Run php artisan route:cache in the same step as your deploy build so route-file changes are exercised before they reach production.

Gotchas and Tips

• v0.3.10 is a routing-layer swap. Replacing Waymaker with native route files changes how routes are registered, which means anything you did that depended on the old abstraction (custom route registration, middleware applied through Waymaker, route names produced by it) needs re-verification. Run route:list before and after the upgrade and diff it — that is the fastest way to catch a renamed route or a dropped middleware.
• Stale route cache is the #1 post-upgrade failure. After upgrading, always:

  php artisan optimize:clear
  

  A cached bootstrap/cache/routes-v7.php from 0.3.9 will happily serve the old routing table and make the upgrade look broken (or, worse, look fine locally and break in prod).
• Route names are part of your public surface. If route('...') calls in your views/controllers reference names the package generated, confirm they survived the Waymaker removal. Grep for the package's route-name prefix.
• Fallback ordering. Native route files are loaded in provider boot() order. A Route::fallback() in your app can shadow package routes if registration order flips between versions — keep the fallback last and test it.
• Pre-1.0 semver. A "route file" refactor shipped as a patch bump (0.3.9 → 0.3.10) signals that breaking-ish changes may not get a major/minor. Read the diff link in the changelog, not just the PR title, and pin "nckrtl/launch-laravel": "0.3.*" until 1.0.
• Debugging routing: php artisan route:list -v shows middleware per route; combined with --path this tells you whether a missing response is a registration problem or a middleware rejection.
• Extension point to watch: if you were relying on Waymaker for anything beyond registration, that extension point is gone. File an issue upstream or vendor the behavior into your own provider — do not reimplement Waymaker locally, or you'll re-inherit the coupling the maintainer just removed.