Orz Stack Laravel Package

Getting Started

orz14/orz-stack is a Laravel stack package that bundles opinionated HTTP-layer concerns — most visibly authentication flow and (until v1.1.8) HTML response minification — rather than a single-purpose library. Treat it as infrastructure: install it, publish its config, and then read the service provider to see exactly what it registers into the HTTP kernel.

Minimal setup:

composer require orz14/orz-stack
php artisan vendor:publish --provider="Orz14\OrzStack\OrzStackServiceProvider"

Then, before writing any feature code:

1. Read the service provider first. This package alters global HTTP behaviour (middleware and login), so the provider's register()/boot() is the source of truth for what it touches. Note which middleware aliases and route groups it injects.
2. Inspect the published config (config/orz-stack.php or similar) and check config/app.php / bootstrap/app.php for auto-discovery. In Laravel 11+ stacks, middleware registration often lives in bootstrap/app.php rather than the kernel — verify where this package hooks in.
3. Check the auth routes and controllers it ships or overrides, and diff them against your app's existing LoginController / Fortify / Breeze setup.

First use case: wire it into a fresh Laravel app as the auth + response layer for an internal admin panel. That is the lowest-risk way to see the login flow and middleware stack in isolation, before retrofitting it onto an existing app where the login override may collide with your current guard configuration.

Implementation Patterns

Layer it under your own auth, don't replace it wholesale. The v1.1.8 login changes indicate this package owns the login path. If your app already has Breeze/Jetstream/Fortify, the safest pattern is to let the package handle the request/response plumbing while your app keeps guard and user-provider configuration in config/auth.php. Point the package's config at your existing guard rather than introducing a second one.

Keep response minification out of the package's hands. v1.1.8 removes the bundled HTML minifier. For new installs, do not look for a minify toggle — there isn't one. If you need whitespace-collapsed HTML in production, implement it yourself as a terminating middleware or at the web-server/CDN layer, where it is observable and independently switchable:

// app/Http/Middleware/MinifyHtml.php — your responsibility now
public function handle($request, Closure $next)
{
    $response = $next($request);

    if (! app()->isProduction() || ! str_contains($response->headers->get('Content-Type', ''), 'text/html')) {
        return $response;
    }

    $response->setContent(preg_replace('/>\s+</', '><', $response->getContent()));

    return $response;
}

Feature-test the login flow, not just the happy path. Since login logic shipped in this release, write tests around: successful login redirect target, failed-login error bag contents, remember-me cookie behaviour, throttling after N attempts, and post-logout session invalidation. The login controller is a package-owned surface — your tests are the contract that catches the next silent change.

Pin the version in composer.json ("orz14/orz-stack": "~1.1.8") while the package is still making behaviour-level changes in patch releases. A ^1.1 constraint would have silently pulled a login rewrite into a patch upgrade.

Integrate via middleware groups, not global middleware, for anything the package offers beyond auth. Global middleware is hard to exclude per-route; group-scoped registration lets you keep the package off public API routes where its HTML-oriented assumptions don't apply.

Gotchas and Tips

• v1.1.8 is a behaviour-changing patch release. Two things changed: HTML minification was deleted, and login logic was updated. Both are things a patch version is not expected to touch. Audit the diff between v1.1.7...v1.1.8 before upgrading a production app rather than trusting the semver.
• Upgrading from v1.1.7 will change your rendered HTML. Any test asserting on exact response bodies (snapshot tests, assertSee with surrounding whitespace, inline <script> formatting) may now fail or, worse, pass misleadingly. If downstream tooling — email templates, PDF renderers, JS that string-matches markup — depended on minified output, that dependency is now yours.
• The login changes are undocumented in the release note. "Update login logic" is not a changelog. Read the actual PR (#22) and the diff of the login controller before deploying. Specifically check: redirect after login, exception handling on invalid credentials, session regeneration, and whether rate limiting was added, removed, or altered.
• Debugging auth regressions: start with php artisan route:list --path=login to confirm which controller is actually serving the route — a package override that loses to your app's route registration is a common and confusing failure. Then check middleware order with php artisan route:list -v.
• Config caching hides published-config changes. After any upgrade, run php artisan config:clear (and route:clear, view:clear) before concluding the package is broken.
• Extension points are thin. With minification gone, the package's remaining surface is auth plus whatever middleware it registers. Prefer decorating its behaviour with your own middleware and route overrides rather than editing vendor files; there is no documented event/hook layer to rely on here.
• Watch the upstream repo, not just the release feed. Given the pace of behaviour changes in patch releases, subscribe to the GitHub releases page for orz14/orz-stack and read diffs before running composer update.