- What is rsc-kit/laravel and what problem does it solve?
- rsc-kit/laravel is a Laravel package that brings server-driven component workflows, specifically React Server Components-style rendering, into a PHP application, alongside Artisan scaffolding commands, reusable helpers, and conventions that cut boilerplate. It keeps component logic on the backend so you ship lighter interfaces with less client-side JavaScript. It also provides primitives such as Rsc::refuse() for server-authoritative UI decisions. Treat it as a frontend architecture commitment rather than a small utility dependency.
- How do I install rsc-kit/laravel in a Laravel application?
- Install it with Composer using composer require rsc-kit/laravel. The package registers itself through Laravel's package auto-discovery, so there is no mandatory manual service provider edit and no required configuration to get started. After installing, run the publish command if you want to customise the config and stubs. Because the package pairs PHP with a JavaScript renderer, also confirm the matching JS-side package version before you build.
- Do I need a Node.js runtime to use rsc-kit/laravel in production?
- Yes in practice. React Server Components in a PHP host imply a second runtime: PHP-FPM serves the Laravel request while a Node process performs rendering, and a Vite bundler step must stay in lockstep with the PHP-side component registry. If your team already builds frontend assets with Vite, you likely have most of the toolchain, but you still take on operating a Node process in production. Budget for that operational overhead as a permanent cost, not a one-off.
- What does Rsc::refuse() do and when should I use it?
- Rsc::refuse() lets server-side logic decline to render a component and hand structured data back to the client, rather than rendering a fallback inside the component tree. It is intended for server-authoritative decisions such as authorization checks, feature flagging, entitlements, per-tenant configuration, and region gating. Keeping those decisions in PHP avoids duplicating the logic in the JavaScript bundle. If your product has no server-authoritative UI branching, you probably do not need this primitive.
- How does Rsc::refuse() interact with Laravel middleware, guards, and policies?
- Refusals should sit alongside, not replace, Laravel's authorization layer. In practice you evaluate the guard, middleware, and policy first, then use refuse() to communicate the outcome to the UI layer as structured data. The release notes do not document exactly where refuse() runs in the middleware stack, so verify the ordering in a spike. Keep policy checks as the source of truth and let refuse() carry the result.
- Is there a client-side JavaScript API for handling refusals, and how is the payload serialized?
- The release notes for 0.15.5 do not document a coordinated JS-side handler API or a versioned serialization format, so verify both before committing. You need to confirm how the refusal payload is shaped, how the client deserializes it, and whether the format is versioned or negotiated between PHP and JavaScript. Also check whether the handler ships in this release or in a paired JavaScript package. Until that contract is documented, treat it as the top risk in your integration spike.
- Can I migrate an existing Blade, Livewire, or Inertia app to rsc-kit/laravel incrementally?
- You can, but only as a bounded, additive surface. Do not attempt a page-by-page migration of an existing Blade, Livewire, or Inertia application, because RSC changes the routing and rendering model and partial adoption leaves you maintaining two paradigms over one layout. The workable approach is to build one new route group or one new product area RSC-first and let it coexist with the existing app behind the same session and auth layer. Expand from there once the pattern is proven.
- Is rsc-kit/laravel stable enough for production at version 0.15.x?
- It is pre-1.0 software, currently at 0.15.5, so the refuse() signature and semantics are not frozen and a minor release could introduce breaking changes. The package is also maintained by a small team with a single visible contributor, and the material reviewed contains no published stability policy, release cadence, or security process. Pin the exact version rather than a caret range, vendor your lockfile, and confirm the paired JavaScript package version explicitly. If you adopt it, do so for one bounded surface first.
- How do I publish the config and stubs to customise generated files?
- Run Laravel's standard vendor:publish command and select the rsc-kit tags to copy the configuration file and the scaffolding stubs into your application. Once published, the generated classes and files can be edited freely, and the Artisan scaffolding commands will use your customised stubs. This is how you move from the sensible zero-config defaults to full control over generated output. Skip publishing entirely if the defaults already fit your conventions.
- Which Laravel and PHP versions does rsc-kit/laravel support, and how should I pin it?
- The package relies on Laravel's package auto-discovery and modern framework conventions, so check the composer.json constraints on the repository for the exact PHP and Laravel version ranges before installing. It also assumes a JavaScript build pipeline, typically Vite, and a Node renderer, so your frontend toolchain needs to support that. Pin the exact package version rather than a caret range and verify the matching JS package version in the same way. Test the pairing in a staging environment before rolling it to production.