- How do I install neo/laravel-early-access in a Laravel application?
- Install it with Composer using composer require neo/laravel-early-access. The package follows standard Laravel conventions, so its service provider is auto-discovered and you then publish the config, views, and migration with the vendor:publish command. Because the last release was in April 2021, expect to loosen the illuminate/* and PHP constraints in its composer.json before it will install on a modern Laravel stack.
- Does neo/laravel-early-access work with Laravel 9, 10, 11, or 12?
- Not out of the box. The latest release dates from April 2021, which places it in the Laravel 8 era, and Laravel 9 through 12 have shipped since then. You will almost certainly need to adjust the composer.json version constraints for illuminate/* and PHP before it installs. On Laravel 11 and later you also need to adapt middleware registration, since the framework skeleton no longer ships an app/Http/Kernel.php.
- Does this package actually gate my whole application, or does it just add a public waitlist page?
- The package is primarily a landing-page convention: a public route, a controller, a Blade view, an email-capture table and model, plus a middleware that gates the rest of the app behind a pre-launch state. Whether the gate is genuinely enforced depends on that middleware being registered and applied correctly, so verify it yourself before relying on it. This single detail changes the risk profile, because a gate that fails open on an exception, a missing config value, or an unmatched route will expose your pre-launch application.
- How do I publish the configuration, views, and migration for neo/laravel-early-access?
- Use Laravel's standard vendor:publish command, targeting the package's service provider tag for config, views, or migrations as needed. Published assets let you edit the waitlist page markup and package settings directly inside your own app. Publishing the migration is required before signups can be stored, so run php artisan migrate afterwards.
- Where does the package store waitlist signups, its own table or the users table?
- It ships its own email-capture table and Eloquent model, which is the safer design for this pattern. Confirm this in the published migration before running it, because writing into an existing users table would be risky: column types and identifier-length defaults have shifted across Laravel majors and can collide with your schema. If it does target users, create a dedicated table instead.
- How do I register the early access middleware in Laravel 11 or 12 without a Kernel.php?
- Laravel 11 removed app/Http/Kernel.php and moved middleware registration to bootstrap/app.php. If the package's documentation only describes the Kernel approach, add the middleware through the withMiddleware callback in bootstrap/app.php instead. This adapter step is straightforward but easy to get wrong, so confirm the gate is actually applied by hitting a protected route while logged out.
- Can I override the waitlist route, view, and controller without forking the package?
- Config and views are publishable, so those are normally safe to customise in your host application. Routes and controllers are less predictable and may be hard-coded in the package's service provider, in which case overriding means registering your own route earlier or extending the controller. Check this before adopting, because needing a fork on day one removes most of the benefit of using a package.
- Is the waitlist signup endpoint protected against spam, bots, and duplicate emails?
- Do not assume so. The package predates current expectations around abuse control, and an email endpoint without rate limiting, a honeypot, or double opt-in is a spam and consent liability rather than a minor inconvenience. Add Laravel's rate limiter, validation, deduplication, and a confirmation step yourself, or wrap the endpoint before launch.
- Is neo/laravel-early-access still maintained, and what should I use instead?
- There has been no release since April 2021, no recent repository activity, and no dependents or production feedback to read. That means you inherit an annual framework-upgrade tax on code you did not write and a maintainer who will not fix it. The pragmatic alternative is to treat it as a reference implementation: read the ten or so files and reimplement the route, Blade form, controller, table, and middleware against your pinned Laravel version in a day or two.
- How do I switch early access mode off on launch day, and how do I test the gate?
- Look for a config flag or environment variable that the gate checks, and verify it can be toggled without a deploy. Write feature tests that hit a protected route both while the gate is on and after it is switched off, so a misconfiguration cannot silently expose the site. If the package has no clean toggle, add one in your own middleware wrapper rather than editing vendor code.